Overview
Replication keeps copies of data on multiple nodes, and the key question is where writes are allowed. Single-leader (a.k.a. primary-replica) sends every write to one leader that streams changes to read replicas — the default for SQL databases. It is simple and conflict-free, but the leader is a write bottleneck and a failover point. Multi-leader lets multiple nodes accept writes (often one per region), improving write availability and local latency, but two leaders can change the same row concurrently, so you must detect and resolve conflicts.
Single-Leader vs Multi-Leader: key differences
| Single-Leader | Multi-Leader | |
|---|---|---|
| Where writes go | One leader only | Several leaders |
| Write conflicts | None (single writer) | Possible — need resolution |
| Write availability | Lost until failover | Survives a leader/region outage |
| Geo latency | Remote writes are slow | Write to a nearby leader |
| Complexity | Low | High (conflict handling) |
When to use Single-Leader
Most applications: a single primary with read replicas is simple, consistent and well-understood — the right default until a specific need forces otherwise.
When to use Multi-Leader
Multi-region write locality, offline-capable or collaborative apps, or when you must keep accepting writes even if one region/leader is down.
Verdict
Start with single-leader — it avoids the hardest problem in replication (write conflicts). Move to multi-leader (or leaderless, like Dynamo/Cassandra) only when multi-region write availability or locality genuinely requires it, and budget for conflict resolution (last-write-wins, CRDTs, or app-level merges).
Common questions
What is the main drawback of multi-leader replication?
Write conflicts: two leaders can modify the same data concurrently, and you must detect and resolve those conflicts (last-write-wins, version vectors, CRDTs, or custom logic). This complexity is why single-leader is the default.
Is single-leader the same as primary-replica?
Yes — "single-leader", "primary-replica", "master-slave" and "leader-follower" all describe the same model: one node takes writes and replicates to read-only followers.