Supabase schema migration drift: the silent deploy breaker

Schema drift happens when the database schema in production no longer matches what your application code expects. A migration was applied locally but not pushed. A column was added directly in the Supabase dashboard but not in a migration file. A migration was applied in staging but failed silently in production. The result is the same: your application makes queries against columns or tables that do not exist, and API calls fail with cryptic errors.

How schema drift accumulates

Drift rarely happens in one dramatic event. It accumulates through small inconsistencies: a developer adds a column in the dashboard during debugging and forgets to create a migration. A migration is run out of order. A rollback removes a migration file but the schema change persists in production. Over time, the gap between "what the code expects" and "what the database has" widens until something breaks visibly.

Detecting drift before it breaks

The only reliable way to detect schema drift is to compare the expected schema (from your migration files) against the actual deployed schema. This comparison should run automatically on every deploy or check cycle, not manually when something is already broken.

Gate releases on schema sync

If your schema is out of sync, deploying new code that depends on the new schema will fail. The deploy gate should hold the release until migrations are applied and the schema matches. This prevents the worst outcome: deploying code that immediately errors for every user because a required column does not exist yet.

PreFlight schema sync detection

PreFlight detects when a Supabase migration diverges from the deployed application. It compares your expected schema state against the live database and gates the release until they match. This runs automatically as part of your check cycle — no manual diffing, no hoping the migration ran correctly. If there is drift, you see it immediately.