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.

When data is copied, SupaClone can also rewrite project URLs stored inside the rows - for example Storage object links pointing at the source project - to the target project ref. Primary key, foreign key, and partition key columns keep their original values, so verification and referential integrity stay intact. See Storage for details.

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.