Supabase Migration Applied But Column Missing: Fix Drift
When a Supabase migration says applied but the column does not exist, don't re-run anything blindly — verify with information_schema, repair the history table, and your schema is trustworthy again in minutes.
Last updated: 2026-10-10 When a Supabase migration says applied but the column does not exist, you can have a trustworthy schema again in minutes — without re-running anything blindly and without touching production data. The trick is to stop trusting the migration history table and check what is actually in the database, then repair history to match reality. This guide shows the exact sequence: verify with information_schema , pick the right migration repair status, and apply the real change. What the error looks like: Supabase migration says applied but column does not exist Your app starts throwing one of these after a deploy: column "avatar_url" of relation "profiles" does not exist Postgres error code 42703 . Or the Supabase-flavored version through PostgREST: PGRST204: Could not find the 'avatar_url' column of 'profiles' in the schema cache Meanwhile supabase migration list (or supabase migration list --linked for the remote project) shows the migration that adds the column as applied . The history table says the work is done. The database disagrees. That disagreement has a name: schema drift — the migration history and the actual schema are out of sync. Why it happens The Supabase CLI tracks migrations in a history table ( supabase_migrations.schema_migrations ). When you run supabase db push , it compares your local migration files against that table and applies whatever is missing. The problem: the table records *that a migration ran*, not *that it succeeded completely* or *that nobody changed the schema some other way afterward*. So the record can lie in both directions. A migration can be marked applied when its statements never actually ran (interrupted push, failed statement swallowed by a transaction edge case). Or someone applied…