Most teams only discover whether their pg_dump backups are usable on the day they need them. BackupDrill, an open-source project announced on the PostgreSQL news page, turns that gamble into a routine check by backing up Supabase Postgres databases to storage you control and then regularly restoring them into a throwaway PostgreSQL instance.
The tool runs pg_dump in custom format against a Supabase project and streams the archive to any S3-compatible bucket — AWS S3, Cloudflare R2, Backblaze B2 or Wasabi — alongside a checksummed manifest. Storage files can be copied into the same snapshot.
- The
backupdrill drillcommand restores the latest snapshot into a throwaway PostgreSQL container usingpg_restore. - Each drill verifies the archive checksum, confirms
pg_restorecompleted, and checks that post-data objects such as indexes, constraints and triggers were created. - It confirms every table is present and that tables which previously held data are not empty, and it records how long the restore took.
- Backups remain plain
pg_dumparchives, so stockpg_restorecan recover them without BackupDrill. - BackupDrill refuses to run a
pg_dumpwhose major version is older than the server's; Supabase currently runs PostgreSQL 15 to 17.
Scope is limited for now: it targets Supabase-hosted PostgreSQL only, dumps the public schema by default, and other schemas require configuration.
For developers, the appeal is moving restore testing from a hoped-for postmortem activity into a scheduled step that fails loudly when an archive is broken. Because the output is a standard dump in a bucket you own, there is no lock-in — if BackupDrill disappears, pg_restore still works. Teams running Supabase in production should treat automated restore drills as a baseline safety check rather than a nice-to-have.