How to download a Supabase database backup

Can’t find a download button for a recent Supabase backup? It may not be a dashboard bug. Supabase uses some backups for restores inside the platform; a portable logical dump is a different thing.

Why the dashboard backup may not be downloadable

Supabase’s current backup documentation explains that newer projects use physical backups and that physical backups are not directly downloadable. Point-in-Time Recovery is also a platform restore mechanism rather than a portable dump file.

This does not mean your database cannot be exported. It means a dashboard recovery point and an independent logical backup are different artifacts. Use the dashboard mechanism for supported in-platform restores and create a logical export when portability or separate retention is required.

Create a logical backup with pg_dump

PostgreSQL’s pg_dump utility exports one database while it remains available to readers and writers. For automated recovery work, the custom format is often useful because pg_restore can inspect and selectively restore its archive.

A typical custom-format export looks like this:

pg_dump --format=custom --no-owner --file=backup.dump "$DATABASE_URL"

Pass the connection string through a secret manager or process environment. Do not paste production credentials into a shell history, CI log or repository. Use a database role with only the permissions necessary to read the objects being backed up.

Choose compatible client tooling

Use a pg_dump version that is compatible with the server. Record both versions alongside the artifact. Database extensions and ownership expectations also matter, so keep an inventory of required extensions and cluster-level roles that pg_dump does not capture.

What a database dump does not include

• pg_dump covers one PostgreSQL database, not cluster-wide roles and tablespaces.
• The actual Supabase Storage object bytes need a separate copy.
• Auth settings, API keys, Edge Function secrets and service configuration need a separate inventory.
• External services such as email, payments and queues have their own recovery boundaries.

Supabase’s restore-to-new-project documentation provides a useful list of items that are and are not transferred. Use it to find assumptions that a database-only runbook would miss.

Store the export independently

Encrypt the dump, upload it to a separate storage account and apply deliberate retention. Capture a checksum before and after transfer. Limit who can delete backups, and monitor both failed jobs and missing expected artifacts.

Independence is especially important for project deletion. Supabase says deleting a project permanently removes its backups along with the database, Storage objects and configuration. An export stored under a separate security boundary covers a different failure mode.

Verify the download by restoring it

1. Provision a clean PostgreSQL target with compatible versions and extensions.
2. Run pg_restore with errors treated as fatal; consider single-transaction mode where suitable.
3. Compare schema objects, row counts, ownership, sequences and domain invariants.
4. Run application smoke tests against the recovery database.
5. Store the verification report and destroy the temporary target.

A successful download proves that bytes moved, not that recovery works. Follow the full PostgreSQL restore testing guide and combine it with separate Supabase Storage backups for application-level recovery.