How to back up Supabase on the free plan
Supabase free plan projects receive no automatic backups. Paid plans get a daily database snapshot, retained 7 days on Pro and 14 on Team; the free plan gets nothing, and Supabase documents that free projects should export their data themselves. If your project matters, arranging a backup is your job from day one.
What has to be copied
A Supabase project is not only a database. Four things need protecting, and they live in different places.
| Component | Where it lives | Covered by a database dump? |
|---|---|---|
| PostgreSQL data and schema | Postgres | Yes |
| Auth users and identities | Postgres (auth schema) | Yes, if the dump includes it |
| Storage files | S3-compatible object store | No, only the catalogue rows |
| Edge Functions and settings | Platform, outside Postgres | No |
The Storage row is the one that surprises people. A database dump keeps the table describing your uploads, so after a restore the catalogue looks complete while every download fails.
Option 1: the Supabase CLI, free
The supported route, and it costs nothing. Take the roles, the schema and the data separately so a restore can be done in the right order:
- Run supabase db dump with the role and schema flags to capture structure.
- Run it again with the data flag for the rows.
- Copy Storage separately with the S3-compatible endpoint and an aws s3 sync.
- Store the result somewhere other than the machine that produced it.
This gives you a portable logical backup you fully control. What it does not give you is a schedule, an alert when the job stops, or any proof the dump can be restored. Those are yours to build.
Option 2: your own scheduled job
The same commands on a cron schedule or a scheduled workflow. Cheap and flexible, and the usual failure mode is silence: a job that stopped weeks ago and told nobody. If you take this route, alert on a missing backup rather than on a failing one, because a job that never runs produces no error.
The trade-offs are set out in what pg_dump and cron leave out.
Option 3: a managed service
Several services back up Supabase projects, and they differ mainly in how much of the project they capture. Some take the database only; others include Storage objects, Edge Functions and configuration. ReviveDB is free for one project, restores the database into an isolated PostgreSQL instance and reports each component it could capture or could not access.
The options are compared side by side, with sources, in Supabase backup tools compared.
The limits we chose for ReviveDB Free
This is not a hypothetical example. ReviveDB Free currently allows one project, a 1 GiB source database, 1 GiB of source Storage and 5 GiB of retained backup data. It runs weekly and keeps the latest three recovery points. Storage backup is included; manual runs are not.
Those values come directly from the plan policy used by the application, not from a separate marketing table. We publish the source because a free-backup recommendation is only useful when its limits are explicit.
How often
Frequency follows from how much work you are willing to redo. A daily copy means an incident can cost you up to a day of writes. For a side project that is usually fine; for anything with paying users it rarely is. Decide the number first, then pick the tool that meets it.
Check that it restores
A finished backup job proves a file was written, not that the file works. Restore it into a throwaway database, make errors fatal rather than warnings, and compare table counts against the source. Until you have done that once, you have an untested copy rather than a backup.
The procedure is in how to test the database layer of a backup.