Product features
A backup is useful when it can be restored
ReviveDB protects Supabase and PostgreSQL databases with scheduled, independent backups. Every accepted backup is restored and checked before it is marked verified.
Core backup and recovery features
Database backup, file protection, verification and recovery are one workflow rather than separate checkboxes.
Consistent PostgreSQL backups
ReviveDB creates a logical PostgreSQL backup from the same exported snapshot used to inventory the source. This avoids comparing a restored database with a source that changed halfway through the backup.
A restore test for every backup
The stored dump is downloaded again, restored into an isolated temporary database and compared with the source. A completed upload is not treated as a verified backup.
Supabase Storage file protection
When you provide a Supabase service-role key, ReviveDB copies the actual Storage object bytes as well as database metadata. Files are read back and checked by byte size and SHA-256.
Automatic scheduling and retention
Choose a backup window, timezone and retention period. Stable per-project scheduling spreads load, catches up after downtime and removes expired backup data automatically.
Regional managed storage
Choose Europe, the United States or Asia-Pacific. ReviveDB manages the underlying private object storage while recording the exact provider and region on every backup run.
Two recovery paths
Restore a verified backup into a separate empty target, or perform a guarded rollback of the connected project. In-place rollback first creates and verifies a safety backup.
What verification compares
ReviveDB records an inventory at backup time and compares it with the isolated restore.
- schemas, tables, columns and PostgreSQL types
- row counts, sequences and current sequence values
- constraints, indexes, views and materialized views
- functions, procedures, triggers and row-level security policies
- supported extensions and their versions
- required Supabase Storage files, sizes and checksums
Controls around the backup
Recovery also depends on access, evidence, retention and a clear operational trail.
- Manual and scheduled backup history
- Short-lived signed database downloads and Storage manifests
- Backup failure, overdue backup and restore-result notifications
- Encrypted database credentials and service-role keys
- Revocable login sessions and a security activity trail
- Project disconnect, account export and account erasure controls
Designed around Supabase recovery boundaries
Supabase database backups and Point-in-Time Recovery do not contain the actual Storage object bytes, and project configuration has its own recovery path. ReviveDB keeps database and optional Storage protection explicit, so a restored object catalogue is not mistaken for restored files.
Cluster-wide roles, role passwords and external platform configuration are outside a logical PostgreSQL dump. ReviveDB reports its verification scope instead of claiming that one artifact recreates every external dependency.
Read the complete Supabase backup guide