What Supabase disaster recovery has to cover
A recovery plan for a Supabase project needs to survive three different failure classes: a bad migration or accidental data deletion inside the project, a Supabase platform incident, and an account-level problem — a locked account, a cancelled subscription, or a project deleted by mistake. Point-in-time recovery inside Supabase only covers the first case, because it lives in the same account and the same infrastructure as the project itself.
An independent backup — stored with a different provider, in a jurisdiction you control, reachable without your Supabase login — is what covers the other two.
Why 'backup succeeded' isn't a recovery plan
Most backup tooling confirms that a dump was taken and an upload finished. Neither step proves the file can become a working database again. Dumps silently truncate on disk pressure, connection drops, or a schema Postgres can’t replay cleanly — and none of that shows up as a failed upload.
ReviveDB closes that gap by restoring every backup into a disposable Postgres instance and comparing table row counts and auth user counts against an inventory captured at dump time. Storage files are copied separately and verified byte-for-byte with SHA-256. If a restore doesn’t work, you find out the same day — not during an incident.
Where the copy lives
Database dumps and Supabase Storage file bytes are stored in encrypted managed object storage in your selected region, separate from Supabase’s own infrastructure and from your Supabase account. Losing access to Supabase doesn’t mean losing access to your backups.
Setting it up
- Connect a project with its Session Pooler connection string.
- Optionally add a service-role key to include Supabase Storage files.
- Backups run on a schedule and each one is restore-tested automatically.
- Download a verified database dump or Storage manifest whenever you need it.