How to Restore a Supabase Backup

For Supabase Pro and Enterprise plans, point-in-time recovery (PITR) lets you restore your database to any point within the retention period (7 days on Pro, 30 days on Enterprise). Go to the Supabase Dashboard > Settings > Database > Backups. Select the Point-in-Time tab. Choose the date and time you want to restore to, then click Restore. Supabase will create a new database state matching that exact point in time. This process can take several minutes depending on database size.

Supabase creates daily automatic backups for Pro plans and above. Go to Dashboard > Settings > Database > Backups > Scheduled Backups tab. You will see a list of available backups with dates. Click Download on the backup you want to restore. For free plan projects, you need to create your own backups using pg_dump before you can restore. The downloaded file is a PostgreSQL dump that can be restored with psql.

1# If you need to create a manual backup first:
2pg_dump "postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:5432/postgres" \
3  --clean \
4  --if-exists \
5  -F c \
6  -f backup_20260327.dump

If your backup is a plain SQL file (created with pg_dump without -F c), restore it using psql. Connect to your Supabase database using the direct connection string (port 5432, not the pooled port 6543) and pipe the SQL file into it. The --clean flag in the original dump means it will drop existing objects before recreating them. Make sure no other applications are actively writing to the database during the restore.

1# Restore a plain SQL backup
2psql "postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:5432/postgres" < backup.sql
3
4# Or restore to a local Supabase instance for testing
5supabase start
6psql "postgresql://postgres:postgres@localhost:54322/postgres" < backup.sql

Custom-format dumps (created with pg_dump -F c) offer more flexibility. Use pg_restore to restore the entire dump or selectively restore specific tables. The --clean flag drops existing objects before restoring, and --if-exists prevents errors if an object does not exist. Use the -t flag to restore a single table, which is useful when you only need to recover specific data.

1# Restore entire database from custom-format dump
2pg_restore \
3  --clean \
4  --if-exists \
5  -d "postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:5432/postgres" \
6  backup_20260327.dump
7
8# Restore only a specific table
9pg_restore \
10  -t products \
11  --data-only \
12  -d "postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:5432/postgres" \
13  backup_20260327.dump
14
15# List contents of a dump file (inspect before restoring)
16pg_restore --list backup_20260327.dump

After restoring, verify that the data is correct and complete. Check row counts for critical tables, verify that RLS policies are in place, and test that your application can connect and query data normally. Compare the restored state against known data points — for example, check whether a specific user record exists or whether the total order count matches expectations. Also verify that functions, triggers, and indexes were restored correctly.

1-- Check row counts for critical tables
2SELECT 'users' AS table_name, count(*) FROM auth.users
3UNION ALL
4SELECT 'profiles', count(*) FROM public.profiles
5UNION ALL
6SELECT 'orders', count(*) FROM public.orders;
7
8-- Verify RLS is enabled
9SELECT tablename, rowsecurity
10FROM pg_tables
11WHERE schemaname = 'public';
12
13-- Check that RLS policies exist
14SELECT tablename, policyname
15FROM pg_policies
16WHERE schemaname = 'public';