Backups vs. replication: what's the difference?

Three Tools That Sound the Same but Aren't

Many developers confuse backups, replication, and point-in-time recovery (PITR). They all involve copying data, but they serve completely different purposes in a disaster recovery strategy.

What Each One Does

Backups

A backup is a frozen snapshot of your data at a specific point in time, stored separately from production. It doesn't change after it's created. It's your last line of defense when everything else fails.

• Best for: accidental deletions, ransomware recovery, data corruption, disaster recovery
• Limitation: you lose all data written after the last backup

Replication (Read Replicas)

Replication creates a live, continuously synced copy of your database. Supabase offers read replicas that mirror your primary database in real-time. But a replica is not a backup.

• Best for: read scaling, high availability, reducing latency
• Limitation: if someone runs DROP TABLE users on the primary, the replica executes it too. Replication copies changes — including destructive ones.

Point-in-Time Recovery (PITR)

PITR uses Write-Ahead Logging (WAL) to record every transaction. You can restore to any specific second within the retention window. Supabase offers PITR as a paid add-on.

• Best for: recovering from a bad migration, accidental DELETE, or rolling back to a specific moment
• Limitation: still lives in the same vendor's infrastructure. If Supabase has a regional outage, PITR goes down too.

Comparison at a Glance

Why Replication Is Not a Backup

This is the most common misconception. A read replica mirrors your primary database in real-time. That means:

Primary DB:     [users: 10,000 rows]  ──→  Replica: [users: 10,000 rows]
                          │
                    DROP TABLE users
                          ▼
Primary DB:     [users: 0 rows]       ──→  Replica: [users: 0 rows]

The replica doesn't protect you from destructive operations. It faithfully reproduces them. If your primary loses data, your replica loses the same data — usually within milliseconds.

A backup, on the other hand, is a point-in-time snapshot that doesn't change. Even if production is wiped, the backup retains the data as it was when captured.

Source: [PostgreSQL Docs — High Availability](https://www.postgresql.org/docs/current/high-availability.html), [Cohesity — 3-2-1 Backup Rule](https://www.cohesity.com/glossary/321-backup-rule/)

Supabase PITR Pricing

Supabase offers PITR as a paid add-on with the following pricing:

PITR is powerful for granular recovery, but it's still same-vendor, same-region. It doesn't satisfy the off-site requirement of the 3-2-1 rule.

Source: [Supabase Docs — Database Backups](https://supabase.com/docs/guides/platform/backups)

The Complete Strategy: All Three Together

1. 1Replication keeps your app available during partial failures
2. 2PITR lets you recover to any second within the retention window
3. 3Off-site backup (Supakeep) protects against vendor-level failures, ransomware, and provides compliance evidence

You need all three. Replication without backups is dangerous. PITR without off-site backup is incomplete. Backups without replication means downtime during recovery.

Source: [Veeam — 3-2-1 Backup Rule](https://www.veeam.com/blog/321-backup-rule.html), [US Chamber — 3-2-1 Rule](https://www.uschamber.com/co/run/technology/3-2-1-backup-rule)

Related reading: why every Supabase project needs its own backups and Supabase backup best practices for small teams.