A Supabase database backup restores your Postgres data. Most projects depend on more than that, and the gaps only show up when you restore into a new project.
Here is what does not come back from the database backup alone.
| What | Where it lives | In the database backup? |
|---|---|---|
| Tables, rows, RLS policies, functions | Postgres | Yes |
| Auth users |
auth schema in Postgres |
Yes, if you back up that schema |
| Storage file contents | Object storage | No, only the metadata rows |
| Edge Function code | Deployed separately | No |
| Edge Function secrets | Project settings | No |
| Passwords of custom database roles | Postgres roles | Need to be reset after a restore |
Storage files
The storage.objects table tells you which files exist. The files themselves are not in it. After a restore the app can list every file and download none of them. You need a separate copy of the bytes, ideally from the same moment as the database backup.
Auth users with pg_dump
A common pg_dump example uses --schema=public to skip the Supabase-managed schemas. That also skips auth, so the restored project has your data but no user accounts. If you dump manually, include auth or dump the full database.
Edge Functions
Function code is deployed from your machine or CI, not stored in Postgres. If the code lives in Git, you can redeploy it. If someone deployed from a laptop and never committed, the database backup will not help. Secrets have to be set again by hand.
Test it once
The only way to know what your backup covers is to restore it into an empty project and use the app. Log in, open a page with images, call a function. Whatever breaks is what your backup is missing.
I wrote a longer comparison of the Supabase backup options and what each one covers. If you'd rather not script all of this yourself, ReviveDB backs up the database, Auth, Storage files and Edge Functions together and test-restores every database backup.
Top comments (0)