BackupDrill

About BackupDrill

BackupDrill exists because of a specific, verifiable gap in how Supabase backups work, and it leads with the gap rather than with the product. Restoring a Supabase database restores the storage.objects table — the metadata — but not the files those rows point at, which live in a separate object store. A restore therefore hands back pointers to files that no longer exist, and the official remedy, point-in-time recovery at $100 a month per project, still skips Storage files. BackupDrill snapshots the database and the Storage files together into a bucket you own on S3, R2 or Backblaze B2, using pg_dump plus a checksummed manifest, with bytes streaming through the service rather than landing on its disks. The genuinely differentiating half is the drill. On a schedule, a temporary Postgres instance restores the latest snapshot and verifies it against the manifest: archive checksum match, table count against the manifest, every populated table restored non-empty, sampled SHA-256 checks on Storage files, and optional application-level invariant checks run as a command. The output is a graded report carrying the measured restore time, and a failure or a snapshot that shrinks more than thirty per cent alerts within fifteen minutes. Setup asks only for the Session Pooler connection string — the plain postgres user, never the service_role key. The backup engine itself is MIT-licensed and installable as a CLI, so the tool can be audited or self-run rather than trusted as a black box.

Key Features

Tags