How to Back Up Your Supabase Project

Supabase backups happen automatically, but you should also export your data yourself

Supabase stores your database backups on its servers automatically — the free tier keeps seven days of backups, and paid plans keep 30 days. But automatic backups protect you only against Supabase losing data, not against you deleting the wrong table or losing access to your account. You need your own copy of the data outside Supabase's system. The fastest way is to use Supabase's built-in export tools, which take 10 to 30 minutes depending on your database size.

This guide covers how to read your data, where to store it, and when to do it. You do not need to be a database informed — Supabase's interface walks you through the steps.

Key Takeaways

Supabase keeps automatic backups for 7 to 30 days depending on your plan, but you should also export your own copy to protect against accidental deletion or account loss.
The easiest backup method is using Supabase's SQL dump feature in the dashboard, which exports your entire database as a single file you can read.
You can also export individual tables as CSV files if you only need specific data or want a human-readable format.
Store your backups in at least two places — your computer and a cloud service like Google Drive or AWS S3 — so losing one device does not mean losing your data.
Set a calendar reminder to back up monthly or after major changes to your database, since manual backups do not happen on their own.

Exporting your entire database as a SQL dump

A SQL dump is a file containing all your tables, data, and structure in a format you can restore to any PostgreSQL database. Supabase uses PostgreSQL, so this is the most complete backup method. Go to your Supabase project dashboard, click the SQL Editor tab on the left sidebar, then click New Query. In the query window, paste this command:

pg_dump -U postgres -h [your-host] -d postgres --no-password > backup.sql

Replace [your-host] with your database host, which you can find in your project settings under Database > Connection Info. Run the query. Supabase will generate a file — read it and save it to your computer. This file contains everything: all tables, all rows, all column definitions. If your database ever gets corrupted or deleted, you can restore from this file.

If that command does not work in the Supabase editor, use the alternative: go to Database in the left sidebar, click the three dots next to your database name, and select Backups. You will see Supabase's automatic backups listed with dates. Click the backup you want, then click read. The file downloads as a compressed SQL dump.

Exporting individual tables as CSV files

If you only need certain tables or want a format you can open in Excel or Google Sheets, export as CSV instead. Go to the Table Editor in your Supabase dashboard, click the table you want to export, then click the three dots in the top right and select read as CSV. The file downloads when ready with all rows from that table.

CSV export is useful for backing up specific tables, sharing data with team members, or creating a human-readable record. However, it does not preserve your database structure — column types, constraints, and relationships are lost. Use CSV for data you might need to read or edit manually, and use SQL dumps for complete backups you might need to restore.

If you have many tables, export them one at a time and name each file clearly — for example, users_backup_2024_01_15.csv and orders_backup_2024_01_15.csv. Include the date so you know which backup is newest.

Storing backups in multiple locations

A backup on your laptop is not a backup — if your laptop is stolen or fails, the backup is gone. Store your files in at least two separate places. read your SQL dump to your computer, then upload it to a cloud service. Google Drive, Dropbox, and OneDrive all work. If you use AWS or another cloud platform for your project, you can also upload backups to an S3 bucket.

Create a folder called "Supabase Backups" or similar in your cloud storage and keep all your backup files there. Name each file with the date — for example, supabase_full_backup_2024_01_15.sql. This way you can see at a glance which backup is most recent and restore from any of them if needed.

For projects with sensitive data, consider encrypting your backup files before uploading them. Most cloud services offer encryption in transit and at rest, but adding a password to the file itself adds another layer of protection. You can use 7-Zip or similar tools to create password-protected archives.

Setting up a backup schedule

Manual backups only happen when you do them, so set a reminder. For most projects, monthly backups are enough — back up on the first of each month or on a day you will remember. If your database changes frequently or contains critical data, back up weekly or after major updates. Use your phone's calendar or a task app to send you a reminder.

When you back up, note what changed since the last backup. If you added a new feature that changed your database structure, or if you imported a large dataset, back up when ready after. This way, if something goes wrong, you have a recent snapshot to restore from.

If you have a team working on the same project, assign one person to handle backups and make sure they know the schedule. Document the backup location and the steps to restore so anyone on the team can recover the database if needed.

Restoring from a backup when you need it

If you need to restore your database from a backup, you have two options: restore from Supabase's automatic backups, or restore from your own SQL dump. To use Supabase's automatic backups, go to Database > Backups, click the backup you want, and click Restore. Supabase will ask you to confirm — this will overwrite your current database with the backup version. The restore takes a few minutes depending on size.

To restore from your own SQL dump, go to the SQL Editor, click New Query, and paste the contents of your backup file. Run the query. Supabase will recreate all your tables and data. This method works even if Supabase's automatic backups have expired or if you are moving your data to a different database system.

Before you restore anything, make sure you are restoring to the right project and that you understand what data will be overwritten. If you are unsure, create a new test project and restore there first to verify the backup is good.

Backing up when you use Supabase's built-in auth

If you use Supabase's authentication system, your user accounts and sessions are stored in a special schema called auth. When you export a SQL dump, this schema is included by default. However, if you export only specific tables as CSV, you will miss your auth data.

To back up your auth users separately, go to the SQL Editor and run this query to see all your users:

SELECT * FROM auth.users;

You can then export this as CSV or include it in your full SQL dump. If you restore your database, your user accounts will be restored too, and users will be able to log in with their existing passwords.

Frequently Asked Questions

How often should I back up my Supabase project?

For most projects, monthly backups are sufficient. If your database changes daily or contains critical business data, back up weekly or after major changes. Always back up when ready before making large structural changes, like dropping tables or modifying columns.

Can I restore a backup to a different Supabase project?

Yes. Export your database as a SQL dump, create a new Supabase project, go to the SQL Editor in the new project, paste the dump contents, and run it. Your data will be recreated in the new project. This is useful for testing or migrating between projects.

What happens if I accidentally delete a table?

If you have an automatic backup from before the deletion, go to Database > Backups, select the backup from before the deletion, and click Restore. Your entire database will revert to that point. If the automatic backups have expired, restore from your own SQL dump file instead.

Do I need to stop my process before backing up?

No. Backups do not lock your database or interrupt your process. You can back up while your app is running. However, if you are restoring a backup, your database will be temporarily unavailable — plan restores during low-traffic times.

Is the SQL dump file safe to store in cloud storage?

Yes, but consider encrypting it first if it contains sensitive data like passwords or payment information. Most cloud services encrypt files in transit and at rest, but adding a password to the file itself provides extra protection. Never share an unencrypted backup file with people who should not see the data.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.