VaultKeep blog

How to back up a Supabase database: every option, honestly compared

Built-in daily backups, point-in-time recovery, pg_dump by hand, the Supabase CLI, and third-party services — what each one covers, what it costs, and the gaps nobody mentions.

Supabase gives you a Postgres database, a Storage bucket for files, Auth, and Edge Functions. When people say "back up my Supabase project" they almost always mean the first two, and most of the options below only cover the first one. Keep that in mind as you read.

Here is every realistic way to back up a Supabase project, with prices as of September 2026. Check the Supabase pricing page before you decide; plans change.

1. Supabase's built-in daily backups (Pro plan and up)

What you get: on the Pro plan ($25/month per organization plus compute), Supabase takes a daily snapshot of your database and keeps seven days of them. You restore from the dashboard, and the restore replaces the current database with the snapshot.

What you don't get:

• Anything on the Free plan. Free projects have no automated backups at all.
• Storage files. Your users' uploads are not part of the database backup.
• Retention beyond seven days on Pro. If a bad migration ran ten days ago, it's gone.
• A copy outside Supabase. The backup lives in the same platform, account and region as the thing it protects. That's fine for "I dropped a table"; it does nothing for "my account was compromised" or "the region had a bad day."
• Proof that the backup restores. Nobody test-restores it until you need it.

Verdict: the right first line of defence on Pro. Not a disaster-recovery plan on its own.

2. Point-in-time recovery (PITR)

What you get: continuous WAL archiving, so you can restore the database to any second inside the retention window. It is the best tool for "someone ran DELETE without a WHERE at 14:32."

What it costs: roughly $100/month for each 7 days of retention, on top of Pro, and it requires at least the Small compute add-on. Enabling PITR replaces the daily backups.

What you don't get: Storage files, an off-platform copy, or anything on Free.

Verdict: worth it for production databases where minutes of data matter. It's a recovery tool, not an off-site backup.

3. pg_dump by hand

What you get: a complete, portable archive of your database that you can store anywhere and restore anywhere, on any plan including Free. This is the workhorse every other option is built on.

# Use the direct connection or the *session* pooler on port 5432.
# The transaction pooler (port 6543) cannot run pg_dump.
pg_dump "$DATABASE_URL" \
  --format=custom --compress=6 \
  --no-owner --no-privileges \
  --file=backup-$(date -u +%Y%m%dT%H%M%SZ).dump

Two things bite people:

1. Supabase-managed schemas. A full dump includes auth, storage, extensions, realtime and friends. Restoring those into a fresh Supabase project conflicts with what the platform already manages there. For migrations, use supabase db dump from the CLI, which knows what to skip. For a raw safety copy, dump everything; you can always restore selectively with pg_restore --schema=public.
2. The pooler. The transaction-mode pooler (port 6543) breaks pg_dump because it can't hold prepared statements across requests. Use port 5432.

What you don't get: scheduling, encryption, off-site storage, retention, alerts or restore tests. You build all of that yourself, and you keep it working.

Verdict: the honest DIY route. We wrote a ten-minute GitHub Actions setup that does the scheduling and off-site part for free.

4. The Supabase CLI: supabase db dump

What you get: pg_dump with Supabase-specific defaults. supabase db dump -f roles.sql --role-only, --schema-only, and --data-only produce SQL files designed to be replayed into another Supabase project. It is the right tool for moving a project between accounts or regions.

What you don't get: the same as raw pg_dump: nothing is scheduled, stored, verified or retained for you.

5. Third-party backup services

A handful of services now back up Supabase specifically. They differ on four points, so ask these questions:

VaultKeep is one of these services, so here is our own answer to those four questions, in the same order: managed storage on Cloudflare R2 by default, or your own S3, Azure, Google Cloud, Oracle, R2 or Backblaze bucket on paid plans; yes, Storage buckets are synced incrementally; yes, every project is test-restored weekly into a throwaway Postgres cluster, including on the Free plan, and table and row counts are compared with the manifest; and yes, one-click restore into an empty project you designate. What we don't do: PITR. If you need second-level recovery, use Supabase's PITR alongside an off-site backup.

Putting it together

Most production projects end up with two of these: Supabase's own backups or PITR for quick rollbacks, plus an off-site copy that is restored on a schedule. If you only have the first, you have a rollback plan, not a backup.