A pg_dump on a cron is not a Supabase backup

Most Supabase backup tools do one thing: run pg_dump on a schedule, put the file somewhere, done. Some pipe it straight into your own Google Drive and never touch it again. That's a reasonable weekend-project solution. It's not what "backup" should mean once real users depend on the project.

Two things are missing, and neither is obvious until you actually need to restore.

The database is not the project

Auth has your users. Storage has their files. Edge Functions have code that was never in Postgres to begin with. A dump gets you the schema and the rows. It doesn't get you back a working project. If someone only backed up the database and Storage is gone, every user's uploaded file is gone with it, dump or no dump.

An uploaded file is not evidence the backup works

pg_dump can finish, upload cleanly, sit in a bucket for six months, and still fail to restore. A connection drops mid-dump, a lock times out, an extension your schema needs isn't installed on the target. None of that shows up in an "upload succeeded" notification. It shows up during the restore, which is the one moment you can't afford a surprise.

We restore every backup into a throwaway Postgres instance and diff it against what was captured: row counts, Storage file hashes, Auth user counts. Free tier included, not a paid add-on. If something doesn't match, the run fails and gets flagged while the original project is still sitting there for you to go look at, instead of finding out mid-incident that the last three months of backups were unusable.

Where the copy lives is the other half of it

A backup that lands in a storage account tied to the same person, same card, same login as the project it's protecting isn't independent of that project's failure modes. We keep recovery points off-platform, in the EU, under a retention policy we set, not one that depends on whoever's Drive quota it landed in.

None of this is complicated. It's just more than a cron job.