Supabase backups by plan, and how to keep your own

On Supabase, the Free plan includes no automatic backups, Pro keeps daily backups for 7 days, Team for 14 days and Enterprise for up to 30. Point-in-Time Recovery (PITR) is a paid add-on that lets you restore to a moment within the last few days instead of the last daily snapshot. None of these include the files in Storage, and deleting a project deletes its backups too, so any app with real users should also keep its own copy outside Supabase.

This guide covers what each plan gives you, what a restore involves, what backups leave out, and a simple routine for your own off-site backups.

What does each Supabase plan back up?

From the Supabase backups docs and pricing page:

The docs specifically recommend that Free projects export their data regularly with the Supabase CLI and keep copies off-site. If your app started as a prototype on the Free plan and now has paying users, this is the first thing to fix.

Daily backups mean you can lose up to a day of data. If the database is restored to this morning's backup, everything written since then (sign-ups, orders, messages) is gone.

What does Point-in-Time Recovery add?

PITR keeps a continuous record of changes, so you can restore to a specific second rather than the last snapshot. According to the docs:

• It's available as an add-on on Pro, Team and Enterprise, and needs at least the Small compute add-on.
• Changes are archived every two minutes or sooner, so the worst case is losing about two minutes of data.
• Pricing depends on how far back you can go: roughly $100 a month for 7 days, $200 for 14 days and $400 for 28 days, on top of compute.
• Turning PITR on replaces the daily backups.

Is it worth it? A simple test: if losing a day of orders, bookings or user content would cost you more than the add-on, yes. For an internal tool or an app whose data you could rebuild, daily backups plus your own exports are usually enough.

What do Supabase backups not include?

This is where people get surprised.

• Storage files. Backups include the database, including the metadata about your files, but not the files themselves. Restoring an old backup doesn't bring back deleted images or documents. You need your own copy of buckets that matter.
• Passwords of custom database roles. If you created your own Postgres roles, their passwords aren't stored in daily backups and must be reset after a restore.
• Anything after deletion of the project. Deleting a project permanently removes its data and its backups.
• Your code and settings outside the database. Edge Function code, Auth settings and environment variables live elsewhere. Keep the code in Git and write down the settings.

What happens when I restore?

Restores are started from Database > Backups in the dashboard. You pick the backup (or the point in time, with PITR) and confirm. While it runs, the project is unavailable, and the downtime grows with the size of the database. Before restoring, the docs say to drop any subscriptions or replication slots you created yourself and recreate them afterwards.

A restore replaces the whole database. If you only need to recover a few deleted rows, a safer approach is to restore into a new project (Supabase calls this duplicating or cloning a project) and copy the rows you need back across.

How do I keep my own backups?

The Supabase CLI wraps pg_dump and produces plain SQL files you can store anywhere. You need the CLI, Docker running, and your database connection string (the session pooler string from the Connect dialog works for most networks). Following the backup and restore guide:

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

That gives you three files: roles, structure and data. The two -x flags exclude internal tables, as the guide's own example does. Keep the connection string in an environment variable and out of scripts you commit.

Turn it into a routine

1. Schedule it. Run the commands daily from a scheduled CI job or a small server. A scheduled GitHub Actions workflow works well, with the connection string stored as an encrypted secret.
2. Store copies outside Supabase, in storage you control in a different account, and keep several days or weeks of history.
3. Encrypt the files. They contain your users' data. Treat them with the same care as the database.
4. Copy Storage buckets separately. Supabase Storage offers an S3-compatible endpoint, so standard S3 tools can sync buckets to another location. Check your project's Storage settings for the connection details.
5. Test a restore. A backup you have never restored is a guess. Every few months, create an empty project and load the files with psql, as the guide shows, then open the app against it.

If you use Supabase Vault or encrypted columns, the guide also notes that the encryption key must be carried over to the new project or the restored secrets can't be decrypted.

What else protects me from losing data?

Backups are the last line. The more common causes of data loss in AI-built apps are a migration that drops a column, an AI agent running a destructive query, or an admin key in the wrong place. Making schema changes through migrations with the Supabase CLI, keeping a separate staging environment and keeping secret keys off the front end prevent most of these. If an agent already deleted something, start with what to do when an AI agent deleted files or data.

Quick answers

Can I download the automatic backups? Backups are listed in the dashboard, but not every type can be downloaded. Your own supabase db dump files are the reliable off-site copy.

Does pausing a Free project delete my data? No, a paused project can be restored, but only for a limited time. See Supabase project paused on the free plan.

How often should I run my own dump? At least daily for an app with active users, and always right before a risky migration.

Is PITR a replacement for my own backups? No. It lives inside the same project and account. Off-site copies protect you against account problems and project deletion.

Not sure your data is safe?

The free App Health Check is a quick first look from outside. If you want backups, restores and keys checked properly, that's part of our Supabase security review, and ongoing care plans can keep an eye on it month to month. Questions are welcome through contact.