Supabase backup verification: why you need a restore drill

Supabase provides daily backups on paid plans. But "backup enabled" does not mean "backup verified." If you have never tested a restore, you do not know whether your backup contains the data you expect, whether it can be restored within your recovery time objective, or whether the backup itself is corrupted or incomplete.

The paused project problem

Supabase pauses inactive free-tier projects after a period of inactivity. A paused project does not run backups. If your project was paused and you did not notice, your most recent backup could be weeks or months old. PreFlight detects paused projects and alerts you before this becomes a data loss event.

What a restore drill verifies

A proper restore drill checks: the backup file exists and is recent, the schema matches what your application expects, critical tables contain data (not empty due to a failed backup), row counts are within expected ranges, and the restore completes within an acceptable time window. This is not about restoring to production — it is about proving the backup is usable.

Schema drift between backup and app

If you run migrations between backups, restoring the most recent backup will give you a database in an older schema state. Your application may fail against this schema. Understand the gap between your backup cadence and your migration frequency. For critical launches, take a manual backup immediately before deploying schema changes.

Automated backup verification

PreFlight's Backup Guard captures a metadata snapshot of your Supabase database on every check run. It detects paused projects, dropped tables, collapsed row counts, and schema mismatches. It runs a read-only integrity drill that verifies your data is currently intact and readable without touching your production database. This happens automatically — no manual SQL dumps or restore scripts needed.