How to Enable Incremental Backups for Supabase

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 (Free & Pro)

All Supabase projects get automatic daily backups retained for a limited window. These are logical backups (pg_dump) taken once every 24 hours.

• Frequency: Once per day.
• Retention: 7 days (Pro), limited on Free tier.
• 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 (Pro and above)

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: Up to 7 days (configurable by plan).
• Granularity: Restore to any point in time, down to the second.
• Recovery: Supabase creates a new project from the WAL stream at the requested timestamp.

Enable PITR from Project Settings → Database → Backups 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 "postgresql://user:pass@db.PROJECT_REF.supabase.co:5432/postgres" \
  --format=custom \
  --no-owner \
  --no-acl \
  -f backup_$(date +%Y%m%d_%H%M%S).dump

pg_restore --dbname="postgresql://user:pass@db.TARGET_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:

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

4. 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 + SupaForge drift detection for config-level changes.

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.