How to Roll Back a Migration in Supabase

List your migrations to find the one you need to reverse. Each migration file in supabase/migrations/ has a timestamp prefix and a descriptive name. Check the supabase_migrations.schema_migrations table to see which migrations have been applied to your remote database. This tells you whether the migration has already been pushed to production or only exists locally.

1# List local migration files
2ls supabase/migrations/
3
4# Check which migrations have been applied remotely
5supabase migration list

Create a new migration file that undoes the changes made by the original migration. If the original created a table, the reverse drops it. If it added a column, the reverse removes it. If it created an RLS policy, the reverse drops that policy. Be careful with destructive operations — dropping a table permanently deletes all data in it. Consider backing up the data before running the reverse migration.

1# Create the reverse migration
2supabase migration new revert_add_products_table
3
4# Then edit the generated file:
5# supabase/migrations/20260327120000_revert_add_products_table.sql

Open the generated migration file and write SQL that reverses each change from the original migration. Work in reverse order — if the original migration created a table and then added an RLS policy, first drop the policy and then drop the table. If the original added a column with data, decide whether you need to preserve that data (copy it to another column or table first) before removing the column.

1-- supabase/migrations/20260327120000_revert_add_products_table.sql
2
3-- Step 1: Drop RLS policies first (they reference the table)
4DROP POLICY IF EXISTS "Users can view products" ON products;
5DROP POLICY IF EXISTS "Users can insert products" ON products;
6DROP POLICY IF EXISTS "Users can update own products" ON products;
7DROP POLICY IF EXISTS "Users can delete own products" ON products;
8
9-- Step 2: Drop indexes
10DROP INDEX IF EXISTS idx_products_user_id;
11
12-- Step 3: Drop the table
13DROP TABLE IF EXISTS products;
14
15-- For column removal instead of table drop:
16-- ALTER TABLE products DROP COLUMN IF EXISTS category_id;

For local development, run supabase migration up to apply the new reverse migration. For production, push the migration to your remote database with supabase db push. The CLI will apply any pending migrations in order, including your reverse migration. Verify the changes by checking the table structure in the Dashboard or running a query in the SQL Editor.

1# Apply locally
2supabase migration up
3
4# Push to production
5supabase db push
6
7# Verify the rollback
8supabase db diff  # Should show no unexpected changes

If a migration was recorded in the history table but failed partially, or if you manually reverted changes in the Dashboard and need to update the migration history, use supabase migration repair. This command marks a specific migration as either applied or reverted without actually running any SQL. Use it to fix inconsistencies between your migration files and the database state.

1# Mark a migration as reverted (not applied)
2supabase migration repair --status reverted 20260327100000
3
4# Mark a migration as applied (already applied manually)
5supabase migration repair --status applied 20260327100000
6
7# Verify the migration status
8supabase migration list

During local development, the fastest way to roll back is supabase db reset. This drops the entire local database, reapplies all migrations from scratch, and runs the seed file. Simply delete or rename the migration file you want to undo before running reset. This approach is only for local development — never use it on a production database.

1# Remove the migration you want to undo
2rm supabase/migrations/20260327100000_add_products_table.sql
3
4# Reset the local database (reapplies remaining migrations + seed)
5supabase db reset
6
7# Or keep the file but reset to test the full sequence
8supabase db reset