CONCEPT Cited by 1 source
Primary vs replica as replication source¶
Definition¶
When a backup process, migration tool, new replica, or CDC consumer needs to replicate from a database cluster, it has a choice of source — the primary node or one of its existing replicas. The choice has a canonical trade-off:
| Source | Freshness | Production impact |
|---|---|---|
| Primary | Most-up-to-date data | Adds CPU / I/O / bandwidth load on the primary |
| Replica | Slightly behind (bounded by replication lag) | Zero additional load on the primary |
Neither choice is universally correct. The right answer depends on: (a) how fresh the downstream needs to be, (b) how much load the replication would add to the primary, (c) whether the primary has spare capacity.
PlanetScale's named choice: primary¶
For backup catchup, PlanetScale reads from the primary VTGate, not from a replica. The reasoning, verbatim (Source: sources/2026-04-21-planetscale-faster-backups-with-sharding):
"If taken from a primary, it will have the most up to date information. If taken from the replica, we avoid sending additional compute, I/O, and bandwidth demand to the primary server. However, in our case, the primary is already performing replication to two other nodes. Also, unless it is the first backup, the primary does not need to send the full database contents to the backup server. It only needs to send what has changed since the last backup, ideally only 12 or 24 hours prior. Thus, having the backup server replicate from the primary is typically acceptable from a performance perspective."
Three structural reasons the primary-as-source choice works for PlanetScale's backup workflow:
- The primary is already replicating. It's already sending binlog to 2 existing replicas; the marginal cost of sending to one more consumer (VTBackup) is small.
- The catchup delta is small. After the first backup exists in object storage, subsequent catchups only transfer 12–24 h of binlog events — typically a small % of total DB size.
- Freshness matters for backups. A backup should be as close to now as possible; reading from a replica would add replication-lag staleness to the backup's as-of time.
Mitigation for primary-load-impact if it becomes a concern: "backups can be scheduled to happen during lower traffic hours."
Alternative framing: replica-as-source¶
When to prefer a replica:
- The primary is already resource-constrained (CPU, I/O, bandwidth).
- The downstream tolerates mild staleness (e.g., analytics pipelines, warm-standby seeding).
- The catchup delta would be expensive (e.g., first-backup bootstrap, large backfill).
- The primary is heavily multi-tenant and the tenant-fairness argument dominates.
patterns/read-replica-as-migration-source canonicalises the replica-as-source choice for zero-downtime migrations.
Related trade-off dimensions¶
- First-backup vs subsequent-backup. First backups transfer full DB; subsequent backups transfer catchup delta. Primary is more expensive for the former, cheaper for the latter.
- Primary replication topology. A primary already replicating to 2 replicas can tolerate a 3rd consumer easily; a primary with 0 replicas would feel the backup load more acutely.
- Consumer count. 1 backup consumer is cheap; dozens of CDC consumers might argue for reading from a dedicated CDC-replica.
Seen in¶
- sources/2026-04-21-planetscale-faster-backups-with-sharding — canonical wiki disclosure. PlanetScale explicitly names the trade-off, chooses primary-as-source for VTBackup catchup, and justifies the choice structurally ("the primary is already performing replication to two other nodes").