Scaling
Replication
Copying the same data to multiple nodes for fault tolerance and read scalability — the central trade-off is durability versus write latency.
Replication copies the same data to multiple nodes, so the system survives a node failure and can spread read traffic across replicas. The most common setup is leader-follower: all writes go to one leader, which then streams changes out to followers.
The client waits until the follower confirms it has the write before getting an ack — durable even if the leader crashes right after, but every write is only as fast as the slowest follower.
Synchronous replication
The leader waits for at least one follower to confirm it has applied the write before telling the client the write succeeded. This guarantees the write survives a leader crash — but write latency is now bounded by the slowest synchronous follower, and if that follower is unreachable, writes can stall entirely.
Asynchronous replication
The leader acknowledges the write to the client immediately, then streams it to followers in the background. Writes are fast and never blocked by a follower — but there’s a window where the leader has data no follower has yet. If the leader crashes in that window, that write is lost, even though the client was told it succeeded.
-- PostgreSQL: require at least one synchronous standby to confirm before commit
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_a, replica_b)';