Deploy

Have backups and test a restore

Know your backup window, take a pg_dump before risky migrations, and test a restore before you need one.

Why it matters

AI-written migrations sometimes drop columns or tables. A backup you have never restored is a guess.

How to fix it

1. Check your plan's backups: Supabase includes daily backups on paid plans, and point-in-time recovery is an add-on.
2. Before risky migrations, take your own dump.
3. Restore a dump into a scratch database once, so you know the steps work.
4. Keep migrations in version control and review destructive statements.

pg_dump "$DATABASE_URL" --format=custom --file=backup-$(date +%F).dump
# restore into a scratch database
pg_restore --clean --no-owner --dbname="$SCRATCH_DATABASE_URL" backup-2026-10-16.dump

How to verify

• You have restored a backup into a scratch database and the data looked right.

Related checks

• Keep previews away from production data
• Enable Supabase RLS on every table
• Log errors without logging secrets

Tick it off in the full checklist