Supabase disaster recovery without relying on Supabase alone
Built-in recovery is useful, but it still depends on the same provider and account. ReviveDB adds a separate route back when the normal one is unavailable.
Supabase project
Capture from the source
ReviveDB recovery point
Stored outside Supabase
Restore or download
Use it when the normal route is unavailable
One provider can fail in more than one way
Disaster recovery matters when the usual route back is damaged or unavailable.
A damaging change
A bad migration, accidental deletion or application bug changes data that you need to recover.
Project or account loss
The project is deleted, ownership changes or the account needed for the normal recovery route becomes unavailable.
A provider incident
Supabase or a dependent service has a wider incident, so recovery tools inside the same platform may not be reachable.
What Supabase disaster recovery has to cover
A useful recovery point needs separation, evidence and enough context to act under pressure.
An independent copy
The recovery point is kept outside the source platform and remains available through another route.
Restore evidence
The database is restored and compared. Other project assets are checked for completeness.
Recovery context
A manifest records what is recoverable and which manual actions remain.
A Supabase recovery sequence you can rehearse
Write the order down before an incident. Each step should have an owner, an expected result and a reason to stop before production traffic moves.
- 1
Choose the last known-good recovery point
Use monitoring, deploy history and audit evidence to bound the incident. Record the selected time and the data that may need to be recreated after it.
- 2
Prepare an isolated target
Create a new project without production traffic. Keep scheduled jobs, outbound webhooks and customer email disabled while recovery is being tested.
- 3
Restore the database and Auth
Apply roles, schema and data in the required order. Compare tables, rows, grants, policies and Auth identities with the recovery-point inventory.
- 4
Restore Storage, Functions and settings
Recreate buckets before uploading object bytes, deploy captured Function bundles and apply the supported non-secret configuration recorded in the manifest.
- 5
Replace project-specific values
Supply new API keys and secret values, then update OAuth callbacks, DNS, webhooks and external-service allowlists. These values do not belong in a backup.
- 6
Test the application before cutover
Verify sign-in, private and public downloads, database writes, Functions and background work. Move traffic only after the checks pass and side effects are deliberately enabled.
Add an independent recovery route
Connect a Supabase project and create a restore-tested recovery point outside the source platform.