Database schema

Cloneable schemas

SupaClone focuses on application-owned schemas. It intentionally excludes Supabase-managed schemas and internal platform objects because those are created and maintained by Supabase on every project.

Common excluded schemas include:

• auth
• storage
• realtime
• extensions
• vault
• supabase_functions
• supabase_migrations

This protects the target from restoring internal objects that Supabase expects to manage itself.

Schema objects

Schema clones use native PostgreSQL dump and restore behavior with SupaClone's Supabase-aware planning around it.

The clone can include:

• Tables and partitioned tables.
• Columns, defaults, generated values, and data types.
• Primary keys, foreign keys, unique constraints, and checks.
• Indexes.
• Views and materialized views.
• Enums and cloneable extensions.
• Functions and triggers.
• RLS enabled state and policies.
• Privileges and default privileges where supported.

Data cloning

Table data is optional. A structure-only run copies schema objects without copying rows. A snapshot run can copy selected table data.

SupaClone can scope data by selected schemas and selected tables. Foreign keys to Supabase-managed schemas, such as auth.users, require extra care because user records are not copied.

Materialized views

Materialized view definitions are part of the schema. Their contents may need a refresh after clone depending on clone mode and application behavior.

After a clone, run:

refresh materialized view your_schema.your_materialized_view;

Use refresh materialized view concurrently only when the materialized view has the required unique index.

Extensions

SupaClone treats extensions cautiously. Application-relevant extensions can be part of the restore, while Supabase-managed or platform-owned extension behavior may remain controlled by the target project.

If an extension needs a manual enablement step, it appears in the clone report.