Supabase backups happen automatically, but you should also export your data yourself
Supabase runs daily automated backups of your database, but those backups live inside Supabase's systems. If you need to move your project, switch providers, or keep a copy you fully control, you have to export the data yourself. The fastest method is using the Supabase dashboard to download a SQL dump. For larger projects or regular backups, you can use the command line or set up automated exports to cloud storage.
This guide covers the three main backup routes: the dashboard export (simplest, takes five minutes), the command-line method (more control, works for large databases), and automated backups to external storage (best for projects you update frequently).
Key Takeaways
- Supabase stores daily backups internally, but you should export your own copy to have full control over your data.
- The dashboard export downloads your entire database as a SQL file in minutes and works for most projects under a few gigabytes.
- The command line gives you more control and handles larger databases, but requires installing the Supabase CLI and PostgreSQL tools.
- Automated backups to cloud storage (AWS S3, Google Cloud Storage, or similar) let you schedule regular exports without manual work.
- Test your backup by importing it into a new Supabase project or local PostgreSQL instance before you need it in an emergency.
Export your database through the Supabase dashboard
The dashboard method is the simplest starting point. Log into your Supabase project, go to the Database menu on the left sidebar, and select Backups. You will see a list of automatic backups Supabase has created. Click the three-dot menu next to any backup and select Download. Supabase generates a SQL file and sends it to your browser — this usually takes a few seconds to a few minutes depending on database size.
Save this file somewhere you can find it later. The filename will be something like backup_2024_01_15.sql. This single file contains your entire database structure and all your data. If your database is larger than a few gigabytes, the download may time out or fail — in that case, move to the command-line method below.
One important note: the dashboard export includes everything except large objects stored in Supabase Storage (files, images, documents). If you use Storage, you need to download those separately through the Storage tab in the dashboard, or they will not be included in your backup.
Use the command line for more control and larger databases
The command-line method gives you more options and handles databases that are too large for the dashboard. You will need the Supabase CLI and PostgreSQL command-line tools installed on your computer. If you do not have them, install the Supabase CLI first by running npm install -g supabase (you need Node.js installed), then install PostgreSQL tools for your operating system — on Mac use brew install postgresql, on Windows download the PostgreSQL installer and select the command-line tools option.
Once installed, open your terminal or command prompt and run supabase login. Supabase will open a browser window asking you to authorize the CLI. After you authorize, return to the terminal. Then run supabase db pull to download your database schema and seed data. This creates a local copy of your database structure.
To export the full database as a SQL file, use pg_dump. You will need your Supabase database connection string, which you can find in the Database Settings page under Connection String. Run pg_dump "your_connection_string" > backup.sql, replacing the connection string with your actual string from Supabase. This creates a file called backup.sql in your current folder containing your entire database.
Set up automated backups to cloud storage
If you update your database regularly, manually exporting each time becomes tedious. You can automate this using a cloud storage service like AWS S3, Google Cloud Storage, or Backblaze B2. The process involves creating a scheduled task that runs a backup script on a timer — either through a cron job on your own server, or through a service like GitHub Actions if your project is on GitHub.
The basic approach: write a script that runs pg_dump to export your database, then uploads the SQL file to your cloud storage bucket. For GitHub Actions, create a file called .github/workflows/backup.yml in your project repository with a schedule (for example, daily at 2 AM) and the commands to run the backup. Supabase's documentation includes example workflows you can copy and modify with your own connection string and storage credentials.
This method requires some familiarity with either server administration or GitHub Actions, but once set up, it runs without any manual work. You get a new backup file in your cloud storage every day (or whatever schedule you choose), and you can download any of them if you need to restore.
Import a backup to test it works
A backup is only useful if you can actually restore from it. Before you rely on a backup, test it by importing it into a new Supabase project or a local PostgreSQL database. This catches problems now, not when you actually need the backup.
To test with a local PostgreSQL database, install PostgreSQL on your computer if you do not have it, then run psql -U postgres -d your_database_name -f backup.sql. This imports your backup file into a local database. If the import completes without errors, your backup is valid.
To test with a new Supabase project, create a new empty project in Supabase, then go to the SQL Editor and paste the contents of your backup file, or use the import function if Supabase offers it. Run the SQL and verify that your tables, data, and functions all appear correctly. Once you confirm the import works, you know your backup can be restored if needed.
Store backups in multiple locations
Keeping all your backups in one place defeats the purpose. If Supabase's systems fail and you only have backups stored on Supabase, you lose everything. Download your exported SQL files to your own computer, and upload copies to cloud storage (Google Drive, Dropbox, AWS S3, or similar). This way, if one location fails, you still have copies elsewhere.
For automated backups, this is already built in — you are storing them in external cloud storage by design. For manual backups, set a reminder to download and store a backup copy every month or every time you make major changes to your database. The small effort now prevents a much larger problem later.
Frequently Asked Questions
Does Supabase keep my automatic backups forever?
No. Supabase keeps automatic backups for a limited time — typically 7 days on free plans and up to 30 days on paid plans. After that, they are deleted. This is why you need to export your own copy if you want a backup you control indefinitely.
Can I restore a backup to the same Supabase project?
Yes, but it will overwrite your current data. Go to the SQL Editor, paste your backup SQL file, and run it. All tables and data from the backup will be restored. If your current project has data you want to keep, export that first or restore to a different project instead.
What if my backup file is too large to download?
Use the command-line method with pg_dump instead. The command line can handle much larger databases than the dashboard download. If the file is still too large to store locally, pipe the output directly to cloud storage using tools like aws s3 cp or gsutil cp.
Do I need to back up my Supabase Storage files separately?
Yes. SQL backups only include your database tables and data, not files stored in Supabase Storage. Download your Storage files through the Storage tab in the dashboard, or use the Supabase CLI command supabase storage download to download entire buckets to your computer.
How often should I back up my database?
For projects that change daily, weekly or daily backups are reasonable. For projects that rarely change, monthly is sufficient. If you use automated backups to cloud storage, there is no harm in running them daily — the cost is minimal and you always have a recent copy if something goes wrong.