Migration History Mismatch - Cannot Create Baseline for Existing Production Database

[farmhutsoftwareteam]

`# Migration History Mismatch - Cannot Create Baseline for Existing Production Database

Problem Description

I have an existing production Supabase project that has been running for several months. I'm trying to set up proper local development with migrations, but I'm facing a migration history mismatch that prevents me from creating a baseline or pulling the schema.

Current Situation

Production Database

• Migrations Applied: 141 migrations (confirmed via Supabase API)
• Status: Live and in use with production data
• Age: Several months in production

Local Repository

• Migration Files: 118 files in supabase/migrations/
• Missing Migrations: 23 migrations that exist in production but not locally
• Issue: Cannot sync or create baseline due to mismatch

What I've Tried

1. Using supabase db pull

$ supabase db pull
Initialising login role...
Connecting to remote database...
The remote database's migration history does not match local files in supabase/migrations directory.

Make sure your local git repo is up-to-date. If the error persists, try repairing the migration history table:
supabase migration repair --status reverted [timestamp]
supabase migration repair --status reverted [timestamp]
[... lists all 141 migrations ...]

2. Starting Fresh Locally

$ supabase stop
$ supabase start
Starting database...
Initialising schema...
Stopping containers...
error running container: exit 1

The local Supabase fails to start, likely due to the 118 migration files trying to apply.

3. Creating New Migrations Directory

• Backed up existing migrations to migrations_backup_[timestamp]
• Created empty migrations/ directory
• Tried supabase db pull - still fails with same mismatch error

The Core Issue

1. Production has 141 migrations in schema_migrations table
2. Local repository only has 118 migration files
3. Some migrations were likely applied directly to production or lost from version control
4. Cannot create a baseline because db pull requires perfect match
5. Cannot start fresh locally because existing migrations fail
6. No documented way to handle this "brownfield" scenario

What I Need

A way to either:

1. Create a baseline migration from the current production state, ignoring the migration history mismatch
2. Reset the migration tracking to start fresh from current schema
3. Force pull the schema despite the mismatch
4. Official guidance on handling existing production databases with incomplete migration history

Environment Details

• Supabase CLI Version: v2.53.6 (update available to v2.58.5)
• Local OS: macOS (Darwin)
• Docker: Docker Desktop 28.3.0
• Database: PostgreSQL production database with extensive schema

Expected Behavior

Should be able to create a baseline migration from an existing production database even when local migration files don't perfectly match the production migration history. This is a common scenario when:

• Taking over an existing project
• Migrations were lost or not committed
• Direct database changes were made in production
• Multiple developers worked without proper migration synchronization

Actual Behavior

Complete inability to establish local development environment or create proper migration baseline due to strict migration history matching requirement.

Related Issues/Discussions

• https://github.com/orgs/supabase/discussions/29545 (Similar issue, unresolved since 2024)

Reproduction Steps

1. Have a production Supabase project with N migrations applied
2. Have a local repository with fewer migration files (N-X files)
3. Try to run supabase db pull
4. Observe migration history mismatch error
5. Try to create baseline - no documented method works

Additional Context

This appears to be a gap in Supabase's tooling for:

• Brownfield projects (existing databases)
• Projects with incomplete migration history
• Teams inheriting existing projects
• Recovery from migration tracking issues

---

Impact: Blocking local development and proper environment separation for production application

Urgency: High - Cannot proceed with development best practices without resolution

Use Case: Establishing proper dev/staging/production environment separation for existing production database`

[farmhutsoftwareteam]

supabase db dump -f
supabase/migrations/00000000000001_baseline.sql

[Rubenburdin]

For anyone else hitting this same wall, thats the key insight here. When your migration history is too far gone to repair, supabase db dump -f supabase/migrations/00000000000001_baseline.sql gives you a complete snapshot of your current production schema as a single file. This bypasses the migration tracking entirely and just captures what actually exists in the database right now.

After creating that baseline, you'll want to clear the migration history on remote with DELETE FROM supabase_migrations.schema_migrations; and then push your new baseline so Supabase knows thats your starting point going forward (https://supabase.com/docs/guides/cli/managing-environments). From there your local and remote are back in sync and db diff will work normally for future changes.

The frustrating part is theres no built in "force pull" or "ignore history" flag in the CLI for these brownfield scenarios. Your suggestion about better tooling for inherited projects is valid, this comes up often enough that it probably deserves a dedicated command or at least clearer docs. The strict matching requirement makes sense for teams with clean histories but becomes a blocker when youre taking over something messy.
For what its worth, teams dealing with data sync issues between their Supabase database and external systems like Salesforce or HubSpot face similar "out of sync" headaches. Thats more the territory where Stacksync helps, keeping actual records consistent across platforms rather than schema definitions. But for migration management, the dump and reset approach you landed on is the right move.

[weissbc07]

I am running into the exact same issue. My local migration history drifted from the remote database after some early manual changes, and Supabase started treating a number of already-applied migrations as missing or failed.

I ended up doing something very similar: iterating through the known migration versions and repairing them as applied since the schema already existed in Postgres. After that, supabase db push and supabase migration up stopped erroring and the local state finally matched reality again.

It feels like the core problem is that there is no clean way to tell Supabase “the schema is correct, the migration history is just out of sync” without manually repairing state. Some kind of official workflow or guardrails here would help a lot, especially since this seems easy to hit on long-lived projects.

Is this the recommended recovery path, or just the least bad option available right now?

[brunocek]

I am on the same boat: https://github.com/orgs/supabase/discussions/41806

[hamedullah49]

https://supabase.com/docs/guides/troubleshooting/new-branch-doesnt-copy-database

This Might Help. ☝🏻