Supabase Backup Guide: Daily Backups, PITR and Your Own Copy

A Supabase backup protects you from a dropped table or a bad migration, but only if you know what your plan keeps, and what it leaves out. The free plan keeps nothing. The paid plans keep database backups inside Supabase, but those backups do not include your uploaded files, and the CLI’s default dump does not include your users. This guide explains each plan, point-in-time recovery and its price, what is missing from every backup, and how to make and restore a complete copy you control.

Facts are from Supabase’s backups documentation, checked on 7 October 2026.

What each plan backs up

The free plan has no automatic backup at all, so a mistake on a free project cannot be undone by Supabase. On paid plans you restore daily backups from the dashboard into the same project.

What a Supabase backup leaves out

Three gaps catch teams out:

1. Uploaded files. Database backups do not include objects stored through Supabase Storage. A restore brings back the rows that point at files, not the files. A file deleted last week stays deleted.
2. Passwords of custom roles. Daily backups do not store the passwords of database roles you created yourself; set them again after a restore.
3. Your users, in your own dump. The CLI’s db dump leaves out Supabase-managed schemas, including auth and storage, by default. A dump made with defaults has your tables but not your sign-ups.

Daily backups or point-in-time recovery

A daily backup takes you back to the start of a day. If a bad migration ran at 4 pm, restoring the morning’s backup also throws away every order and sign-up since then.

Point-in-time recovery (PITR) archives the database’s write-ahead log every two minutes, so you can restore to almost any moment, with at most about two minutes of data lost. It needs at least the Small compute size, and turning it on replaces daily backups.

Before choosing, compare the PITR price with the compute size it requires. Our Supabase pricing guide has both.

What a restore actually does

A restore replaces the project’s database. The project is unavailable while it runs, and the time grows with database size. Logical replication slots and subscriptions are not carried over and must be recreated. If you want to inspect old data without touching production, restore into a new project instead, using Supabase’s project duplication.

Why you should keep your own copy

A backup that only the provider can restore does not help if you cannot reach the provider. Indian developers saw this in February 2026, when supabase.co was unreachable on several Indian networks for about ten days. A copy you hold also lets you:

• restore into any PostgreSQL host if you decide to move
• keep a monthly copy for longer than the plan’s retention
• test a risky migration on a real copy of production

Find the right connection string

Use the Session pooler connection string from the Connect panel, on port 5432. The direct connection works only over IPv6 unless you pay for the IPv4 add-on, and the transaction pooler on port 6543 is not suitable for dumps. Keep the string in an environment variable so the password does not end up in your shell history.

Make a backup you own

The Supabase CLI wraps pg_dump and leaves out Supabase’s internal schemas, which makes the files easy to restore elsewhere. Make three files:

supabase db dump --db-url "$SESSION_POOLER_URL" -f roles.sql --role-only
supabase db dump --db-url "$SESSION_POOLER_URL" -f schema.sql
supabase db dump --db-url "$SESSION_POOLER_URL" -f data.sql --use-copy --data-only

Include your users

If you use Supabase Auth and want your users in the copy, dump the auth schema’s data as well, with plain pg_dump:

pg_dump "$SESSION_POOLER_URL" --data-only --schema=auth --exclude-table=auth.schema_migrations -f auth_data.sql

Restore it only into another Supabase project, where the auth tables already exist. The migrations table is left out because the target project has its own; on plain PostgreSQL there is nothing to restore it into.

Include your files

Storage files need their own copy. Supabase Storage offers an S3-compatible endpoint, so a tool such as rclone or the AWS CLI can copy every bucket to storage you control. Schedule it alongside the database dump so the rows and the files match.

Restore it on any Postgres

Restore the database files in order, stopping at the first error. The last command sets session_replication_role, which needs a superuser on most managed hosts; where your user is not one, restore the data without it and load parent tables first.

psql "$TARGET_URL" -v ON_ERROR_STOP=1 -f roles.sql
psql "$TARGET_URL" -v ON_ERROR_STOP=1 -f schema.sql
psql "$TARGET_URL" -v ON_ERROR_STOP=1 -c "SET session_replication_role = replica" -f data.sql

On a non-Supabase target, three things may fail and need editing first: grants and policies that name Supabase’s anon, authenticated and service_role roles (create those roles first, or remove those lines), foreign keys to auth.users, and row level security policies that call auth.uid(). All three belong to Supabase. We cover them in moving off Supabase.

A simple backup routine

1. Before every schema change: make your own dump.
2. Weekly: dump the database and copy the storage buckets, and keep at least four weeks.
3. Monthly: restore the latest dump into a scratch database and run a few queries. A backup you have never restored is a guess.

Backups on a managed Postgres in India

If you move your database, check the backup terms before you rely on them. On Voroa’s managed PostgreSQL, paid sizes have nightly backups that you turn on with one switch, plus an on-demand Back up now; the free size is not backed up. Details are in managed databases. To bring an existing database across without making dump files, use the database import, which copies from a connection string.

FAQ

Does Supabase back up free projects?

No. The free plan has no automatic backups. Make your own dump regularly, especially before changing the schema. Other free-plan gaps are in Supabase free tier limits.

Does a Supabase backup include Storage files?

No. Database backups cover the database only. Copy your buckets separately through the S3-compatible endpoint.

Can I restore a Supabase backup to a different provider?

The built-in backups are restored from the Supabase dashboard into a Supabase project. A dump you make yourself, as above, restores into any PostgreSQL database.

How much data can I lose with PITR?

Supabase archives the write-ahead log every two minutes, so in the worst case about two minutes of writes.

Keep your database and its backups in India

Create a PostgreSQL database in Mumbai, turn on nightly backups on a paid size, and keep your own dump alongside. Steps for connecting are in creating and connecting a database.