Databases & Storage

ReviveDB adds schema-verified Supabase PostgreSQL 17 backups with full restore testing

Key Takeaway

ReviveDB validates Supabase PostgreSQL 17 backups by performing actual restores into temporary databases and comparing complete schema inventories including constraints, RLS policies, and grants rather than relying on row counts alone.

Summary

ReviveDB, a backup service for Supabase projects running PostgreSQL 17, has introduced restore-tested verification that goes beyond conventional backup checks. The service restores every backup into a temporary PostgreSQL database and compares it against a comprehensive inventory of the source database, covering tables, rows, columns, constraints, indexes, sequences, views, functions, triggers, row-level security policies, grants, and extensions. This approach catches restoration failures that row-count validation would miss, such as missing constraints or policies.

Each backup run operates under a dedicated short-lived read-only PostgreSQL role that can read rows protected by row-level security. Recovery points encompass not only the database but also Auth data, Storage files, and Edge Functions. Users can restore to a new Supabase project or to the original project after rehearsing on a copy. The service is available free for one project.

How ReviveDB's restore verification works

  • Schema-level inventory comparison: The verification compares tables, rows, columns, constraints, indexes, sequences, views, functions, triggers, RLS policies, grants, and extensions between source and restored databases, not merely row counts.
  • Temporary restore validation: Every backup is restored into a temporary PostgreSQL database before being marked as verified, catching corruption or incomplete restores that checksum-only approaches miss.
  • RLS-aware read-only roles: Each backup run creates its own short-lived, read-only PostgreSQL role that can read rows behind row-level security policies, ensuring complete data capture without privilege escalation.
  • Cross-service recovery points: A single recovery point includes Auth data, Storage files, and Edge Functions alongside the PostgreSQL database, enabling full project restoration rather than database-only recovery.
  • Rehearsal workflow support: Restores can target a new Supabase project or the original project after testing on a copy, supporting disaster recovery drills without production risk.

Why it matters

For organizations running production workloads on Supabase's managed PostgreSQL 17, ReviveDB addresses a critical gap in backup trust by proving restorability rather than merely asserting it. This matters particularly for applications relying on row-level security policies and complex schema objects that traditional backup tools may silently fail to reconstruct. The free tier for single projects lowers the barrier for developers to adopt verified backup practices, while the open verification methodology could pressure broader backup tooling to move beyond superficial integrity checks.

Original reference: www.postgresql.org →