Your app's code lives in Git. Your app's data lives in one Postgres database, and on a free Supabase project nobody is backing it up for you. If you vibe coded the app in a weekend, this is the step that's easiest to skip and most painful to miss. Here's how to back up a Supabase database on any plan, and how to restore it.
This guide explains how to back up a Supabase database: what Supabase backs up automatically on each plan, how to export your own backup with the Supabase CLI, how to restore it, and what a backup does not include. The commands come straight from Supabase's documentation, linked throughout.
What Supabase backs up automatically
Supabase's backup docs set out what each plan gets:
| Plan | Automatic daily backups |
|---|---|
| Free | None. Supabase recommends regular exports with the CLI and off-site backups. |
| Pro | Last 7 days |
| Team | Last 14 days |
| Enterprise | Up to 30 days |
Daily backups appear under Database > Backups in the Dashboard, and you can restore a project to any of them. Restoring makes the project inaccessible while it runs, so plan for downtime.
For finer recovery, Pro, Team and Enterprise projects can add Point-in-Time Recovery (PITR), which lets you restore to a chosen moment with up to seconds of granularity. It needs at least a Small compute add-on, it replaces daily backups when enabled, and it's priced by retention period. Check Supabase's pricing table on the backups page before you turn it on.
What a Supabase backup does not include
Read this part twice. According to Supabase:
- Storage objects aren't in database backups. The database only holds metadata about files uploaded through the Storage API, so restoring a backup doesn't restore deleted files.
- Custom role passwords aren't stored in daily backups. After a restore, you reset them.
- Deleting a project deletes its backups. When you delete a project, Supabase permanently removes all associated data, including backups. That's irreversible.
The last point is the strongest argument for keeping your own copy somewhere outside Supabase, whatever plan you're on.
How to back up a Supabase database with the CLI
Supabase documents a three-file logical backup using supabase db dump (Supabase backup and restore with the CLI). You need:
- The Supabase CLI and Docker Desktop, which the CLI dump uses.
- Your connection string from Connect on the project dashboard. Supabase says to use the Session pooler string by default, or the direct string if your network supports IPv6 or you have the IPv4 add-on.
- Your database password in place of
[YOUR-PASSWORD].
Then run the three commands, replacing [CONNECTION_STRING]:
supabase db dump --db-url [CONNECTION_STRING] -f roles.sql --role-only
supabase db dump --db-url [CONNECTION_STRING] -f schema.sql
supabase db dump --db-url [CONNECTION_STRING] -f data.sql --use-copy --data-only -x "storage.buckets_vectors" -x "storage.vector_indexes"
You now have the roles, the schema and the data as plain SQL files. Treat them like the database itself: they contain your users' data, so store them encrypted, somewhere access-controlled, and never in your Git repository. Our guide to Git basics for vibe coders shows how to keep files like these out of commits with .gitignore.
If your project uses Edge Functions, back up their code too. Supabase documents supabase functions download YOUR_FUNCTION_NAME --project-ref your_project_ref, which doesn't include import maps or deno.json files, so keep those in your repository.
How to restore a Supabase backup
To restore into a project you created yourself, Supabase uses psql with the three files in order:
psql \
--single-transaction \
--variable ON_ERROR_STOP=1 \
--file roles.sql \
--file schema.sql \
--command 'SET session_replication_role = replica' \
--file data.sql \
--dbname [CONNECTION_STRING]
--single-transaction and ON_ERROR_STOP=1 mean the restore either completes or changes nothing. If the old database used Realtime, re-enable publications on the needed tables under Database > Publications afterwards.
Make backups a habit, not a one-off
A backup you've never restored is a hope, not a backup. A simple routine:
- Export on a schedule. Weekly for a side project, daily for anything with paying customers. Ask your agent to write a script that runs the three commands and names files by date, and have a human review where the files end up.
- Store copies off-site, outside your Supabase organization, so deleting or losing access to a project doesn't take the backups with it.
- Back up Storage separately if users upload files.
- Test a restore into a fresh project every few months, and time it. That number is how long you'd be down.
Being able to export and restore your data whenever you want is a big part of owning your code and data, and Quebec's Law 25 data portability rules make it a compliance question too.
Keep reading
- How to vibe code a SaaS with Supabase and Vercel in a weekend
- Supabase RLS audit skill for coding agents
- How to build a bilingual app for Quebec with AI
FAQ
Does Supabase back up free projects?
No. Supabase automatically backs up Pro, Team and Enterprise projects. For free projects, Supabase recommends regular exports with the CLI db dump command and off-site backups.
How do I export my Supabase database?
Install the Supabase CLI and Docker, then run supabase db dump three times with your connection string: once with --role-only, once for the schema, and once with --data-only and --use-copy.
Do Supabase backups include Storage files?
No. Database backups only include metadata about files stored through the Storage API, so back up Storage objects separately.
What happens to backups if I delete a Supabase project?
They are deleted. Supabase permanently removes all data for a deleted project, including backups, and the action is irreversible.