GUIDE

How to Enable Incremental Backups for Supabase

Point-in-time recovery, logical backups, and practical strategies for every plan tier.

The SupaForge CLI is open source and on npm: npm install -g @akal/supaforge. A hosted dashboard is on the way - to hear when it opens.

Why Backups Matter

A backup strategy is orthogonal to drift detection - but they complement each other. Drift detection tells you what changed; backups let you undo it. Together, they form a complete safety net for your Supabase project.

Supabase Backup Flavours

Supabase offers different backup mechanisms depending on your plan tier. Understanding the differences helps you choose the right strategy.

1. Daily Backups

Supabase takes automatic daily backups of projects on paid plans, kept for a window that depends on the plan.

  • Frequency: Once per day.
  • Retention: depends on your plan.
  • Granularity: Full database snapshot - no incremental restore.
  • Recovery: Restore to the exact time the backup was taken.

For many projects, daily backups are sufficient. The gap is the last 24 hours of data between backups.

2. Point-in-Time Recovery (PITR)

PITR uses WAL (Write-Ahead Log) archiving to let you restore to any second within the retention window - not just daily snapshots.

  • Frequency: Continuous - every transaction is archived.
  • Retention: chosen when you enable it.
  • Granularity: Restore to any point in time, down to the second.
  • Recovery: restore the project to the chosen moment from the dashboard.

PITR is an add-on for paid plans, enabled from the project's backup settings in the Supabase dashboard.

3. Logical Backups (Self-Managed)

You can take your own backups using pg_dump against the Supabase connection string. This gives you full control over frequency, retention, and storage location.

pg_dump backup
pg_dump "postgresql://user:[email protected]_REF.supabase.co:5432/postgres" \
  --format=custom \
  --no-owner \
  --no-acl \
  -f backup_$(date +%Y%m%d_%H%M%S).dump
Restore from dump
pg_restore --dbname="postgresql://user:[email protected]_REF.supabase.co:5432/postgres" \
  --no-owner \
  --no-acl \
  backup_20250101_080000.dump

Schedule this with cron for incremental protection between Supabase's daily backups:

Cron: every 6 hours
0 */6 * * * /path/to/backup-script.sh >> /var/log/supabase-backup.log 2>&1

4. SupaForge Snapshots

A database backup restores rows. supaforge snapshot records what a backup alone doesn't describe well: the project's structure and configuration - schema, RLS policies, grants, storage buckets and policies, cron jobs, webhooks, Realtime, extensions - plus the rows of your reference tables. Each snapshot is a set of readable files you can commit, diff and keep for as long as you like. It isn't a backup: it holds no rows beyond those reference tables, and no stored files.

Snapshot, and record what changed since the last one
supaforge snapshot --env=production --migration --apply

--migration also writes the incremental migration since the previous snapshot. supaforge restore rebuilds an empty database - Supabase or plain PostgreSQL - from a snapshot, in one transaction:

Restore into a fresh database
supaforge restore --env=local --from-snapshot=latest --apply
Keep the most recent snapshots
supaforge snapshot --prune --keep=14 --apply

5. Logical Replication (Advanced)

For near-zero RPO (Recovery Point Objective), set up logical replication from your Supabase project to an external Postgres instance. Every committed transaction is streamed in real time.

This is the most complex option and is typically used by teams with strict compliance requirements.

Choosing a Strategy

  • Hobby / side project - Daily backups are fine. Supplement with occasional pg_dump before risky changes.
  • Production SaaS - Enable PITR. Add pg_dump to a cron schedule as a secondary safeguard.
  • Regulated / enterprise - PITR, logical replication to an external host, and SupaForge snapshots and drift checks for the configuration.

How SupaForge Complements Backups

Backups protect your data. SupaForge protects your configuration. A backup restores rows - but it won't tell you that an RLS policy was removed, an auth provider was disabled, or a cron job was deleted.

Use both together:

  1. SupaForge scans detect configuration drift across environments.
  2. Backups provide a recovery path when data is lost or corrupted.
  3. Together, they give you full coverage of both data and configuration.

Summary

Supabase offers daily backups and PITR depending on your plan. Supplement with self-managed pg_dump backups for extra control. Combine with SupaForge drift detection to cover the configuration surface that backups alone cannot protect.

Ready to try SupaForge?

Install the CLI and run your first diff in a minute. Nothing is changed until you add --apply.

npm install -g @akal/supaforge
View on GitHub →