Restore a recovery point

A verified recovery point can replace the state of its connected project or populate a separate empty Supabase project.

Before any restore

• Choose a verified recovery point and review its component badges and recovery report.
• Pause application writes. Requests may fail while database and Storage state are changing.
• Confirm that the target Supabase project runs a Postgres major version the same as, or newer than, the backup and supported by ReviveDB.

Roll back the current project

ReviveDB first creates and verifies a fresh safety backup of the current state. Only then does it restore the selected database in one transaction and reconcile Storage to the selected snapshot.

1. Pause application writes and open the verified recovery point.
2. Choose Restore whole project, then Current project.
3. ReviveDB requests a temporary read-write login from Supabase for this restore.
4. Acknowledge the write pause and type the displayed project reference.
5. Keep writes paused until the restore result and recovery report are available.

Restore to a new project

Use a separate, empty Supabase project when you want isolation from the damaged source or need to prepare a controlled cutover. ReviveDB restores the database, Auth state, Storage files, Function bundles and supported configuration through their appropriate database or API paths.

1. Create an empty Supabase project in the desired region and a supported Postgres version.
2. Choose New project in the restore dialog and provide the requested temporary target access.
3. After the automated restore, follow the recovery report for secrets, API keys, DNS and external services.
4. Validate the application before directing production traffic to the new project.

After the restore

• Review restored row counts and component results. Any verifiable mismatch fails the restore.
• Reconfigure secret values and target-project API keys listed in the report.
• Run an application-level smoke test before resuming writes or switching traffic.