Databases & SQL

Database Replication Explained: Leader-Follower and Quorum Reads

Replication answers a simple question — what happens if this server dies — but every way of answering it trades away either latency, consistency, or durability. Nobody gets all three for free.

Published July 6, 2026

Replication means keeping copies of the same data on multiple database servers. The reasons are usually some mix of: survive a server failure without losing data, offload read traffic from a single machine, and serve reads from a server physically closer to the requester. How you get there depends entirely on how strict you need the copies to stay in sync.

Leader-follower replication

The most common setup designates one node the leader (or primary), which accepts all writes, and one or more followers (replicas) that receive a continuous stream of changes from the leader and apply them locally. Reads can be served from either the leader or a follower; writes must go through the leader.

PostgreSQL implements this with streaming replication: the leader ships its write-ahead log (WAL) to each follower, which replays those log records to stay in sync. Setting up a follower typically starts with a base backup, then a continuous WAL stream:

# On the follower, after restoring a base backup with pg_basebackup:
# postgresql.auto.conf
primary_conninfo = 'host=leader.internal port=5432 user=replicator'
primary_slot_name = 'follower_1'

The mechanics of setting primary_conninfo, replication slots, and monitoring replay lag are covered in PostgreSQL's own documentation on log-shipping standby servers.

Synchronous vs asynchronous: the actual trade-off

Asynchronous replication is the default in most setups: the leader commits a write and returns success to the client immediately, without waiting for any follower to confirm it received the change. This keeps write latency low, but it means if the leader crashes a split second after committing, any writes that hadn't yet reached a follower are gone — promoting that follower to leader loses recent data.

Synchronous replication makes the leader wait for at least one follower to acknowledge the write before returning success to the client. That closes the data-loss window but adds the follower's round-trip latency to every write, and if the synchronous follower becomes unreachable, writes can stall entirely until it's back or you reconfigure which follower is synchronous. Most production setups pick a middle ground: one synchronous follower for durability, with additional asynchronous followers purely for read scaling.

Replication lag is a real, visible problem

With asynchronous followers, there's always some delay between a write landing on the leader and that write becoming visible on a follower. If your application writes a record and then immediately reads it back from a follower that hasn't caught up yet, the user sees stale or missing data — a classic bug in systems that naively route all reads to replicas. The usual fixes are: route read-after-write operations to the leader specifically, track a "read your own writes" token that the client passes to ensure the follower it reads from has caught up to at least that point, or simply accept eventual consistency where the use case tolerates it (a public comment count, a dashboard that refreshes periodically).

Quorum reads and writes: no single leader

Systems like Cassandra and DynamoDB skip the single-leader model entirely and instead replicate each piece of data to N nodes, requiring a write to succeed on W of them and a read to check R of them before returning. When W + R > N, every read is guaranteed to overlap with at least one node that has the latest write, which gives you consistency without a single leader as a bottleneck or single point of failure. The cost is complexity: you're now tuning W, R, and N per use case, and conflicting writes to the same key from two nodes during a network partition need an explicit resolution strategy (last-write-wins, vector clocks, or application-level merge logic).

Picking a starting point

For most applications, asynchronous leader-follower with one synchronous replica for durability is the right default — it's what managed services like RDS and Cloud SQL set up by default, and it's well understood operationally. Reach for quorum-based, leaderless replication only once you've hit the specific problem it solves: needing writes to survive the loss of an entire data center without a failover pause, at a scale where a single leader genuinely can't keep up.