Can You Regenerate Your Schema from Supabase?

Yes. If you already have a Supabase database, you can use it to generate—or refresh—the SQL files that describe your declarative schema. You do not have to recreate every object by hand.

The important distinction is what you are regenerating: the current schema definitions, not the migration history that produced them. That distinction determines which command to use and what you need to check before returning to your normal development workflow.

Two Commands for Two Starting Points

Supabase’s declarative tooling supports two closely related operations:

Your starting point	Command	Intended use
An existing linked database, without an established declarative schema tree	`supabase db schema declarative generate --linked`	Initially generate per-object SQL files
An existing `supabase/schemas/` tree that needs to reflect the linked database	`supabase db pull --declarative`	Refresh the local schema files
An existing tree that you explicitly want to replace using generation	`supabase db schema declarative generate --linked --overwrite`	Regenerate without an overwrite prompt

The first command is the easier entry point when you are adopting declarative schemas for an existing project:

supabase db schema declarative generate --linked

Here, --linked means the linked Supabase database supplies the schema definitions. The command exports those definitions into per-object SQL files, giving you a local representation to inspect, version, and subsequently edit.

If you already maintain those files, Supabase recommends the refresh-oriented command:

supabase db pull --declarative

According to the Supabase declarative schema documentation, this replaces the schema files without creating a migration or changing migration history.

That makes it useful when the database has changed independently of your local declarative files.

What “Regenerate” Actually Means

The word regenerate can imply several different operations. Here, it means reconstructing the local schema definitions from the database’s current state.

It does not mean reconstructing the sequence of migrations that led to that state.

A regenerated declarative schema tells you what the database looks like now. It does not tell you how the database got there.

Consider a table that acquired a new column through a change made outside your declarative workflow. Refreshing the schema files can bring that column into the local definition. But the refresh does not create a migration documenting the change, nor does it update migration history on your behalf.

You therefore need to keep three things distinct:

Database state: the schema currently present in the linked database.
Declarative schema files: the local SQL definitions representing the schema you intend to maintain.
Migration history: the recorded changes used to evolve the database.

Regeneration reconciles the first two by taking the database as the source. It does not automatically reconcile the third.

Refreshing an Existing Schema Tree Safely

For an established project, the practical refresh sequence is short:

supabase db pull --declarative
git diff -- supabase/schemas/

The second command matters as much as the first. Refreshing replaces local definitions, so you need to review exactly what changed.

1. Confirm the linked project

Before running either command, check which Supabase project is linked.

The operation reads from that database. If you are linked to the wrong environment, the resulting files can accurately represent the wrong schema. A successful command is not proof that you selected the intended source.

2. Preserve intentional local edits

Look at any uncommitted changes in supabase/schemas/ before refreshing.

Suppose you have edited a table definition locally but have not yet applied that change to the database. A database-driven refresh can replace that edit with the database’s current definition. The refresh is behaving correctly, but it may discard the desired state you were still working toward.

Commit or otherwise preserve edits you need before replacing the tree.

3. Review the resulting diff

After the refresh, inspect:

git diff -- supabase/schemas/

Check whether the changes correspond to the database changes you expected. Pay particular attention to definitions that were replaced or removed and to local edits that are no longer present.

The question is not merely “Did the export succeed?” It is:

Does this refreshed tree represent the schema I now want to maintain?

4. Check migration history before the next `sync`

Before returning to migration generation, make sure your migration history matches the database.

A fresh set of declarative files is not evidence that migration history is aligned. If changes happened outside the normal workflow, that alignment remains a separate concern.

Where Regeneration Fits in the Workflow

The normal declarative workflow starts with your files:

Edit the declarative schema definitions.
Run sync to create a migration.
Continue through your migration workflow.

Regeneration reverses the direction of authorship: the database becomes the source for the files.

That is appropriate in two main situations:

Initial adoption: you have an existing linked database and want a declarative starting point.
Out-of-workflow changes: the database changed independently, and you want your local definitions to reflect its current state.

It is not the right default if your local files contain intentional changes that the database does not yet have. In that case, refreshing from the database can move the files backward rather than move the database forward.

The Practical Answer

Use:

supabase db schema declarative generate --linked

to establish declarative schema files from an existing linked database.