Primary-Replica Replication Lab (Interactive)
Drive write load through the Primary and watch WAL streaming, replica lag, and stale reads react live. Model a PostgreSQL-style leader-follower cluster: writes append to the Primary WAL and stream asynchronously to read replicas that scale reads linearly.
Primary-Replica Replication & Lag Simulator
Drive write load through the Primary and watch WAL streaming, replica lag, and stale reads.
Replica Capacity (reads)
45k r/s
3 nodes x 15k
Est. Stale Reads
0.0/s
eliminated by pinning
Primary Utilization
35%
writes do NOT scale with replicas
Max WAL Lag
17 ms
async streaming delay
lag: 14 ms
reads: 25,333/s
lag: 12 ms
reads: 25,333/s
lag: 17 ms
reads: 25,333/s
Lag grows super-linearly as write load approaches the Primary's 20k writes/s ceiling: each extra replica adds WAL streaming overhead. Read replicas scale reads linearly but never scale writes — that requires sharding.
How It Works Under the Hood
Read-heavy workloads hit a single-node ceiling fast, so Primary-Replica replication copies the WAL byte stream to followers that serve SELECT traffic. Every added replica multiplies read capacity but never write capacity: all mutations still serialize through the one leader, and each extra replica adds WAL streaming overhead that inflates lag. Asynchronous streaming means replicas answer with stale rows until replay catches up, which breaks read-your-own-writes guarantees for users who just saved something.
Core Architectural Principles
- Primary appends every committed mutation to the WAL; walsender streams it to replica walreceivers over TCP.
- Replication lag grows super-linearly as write load approaches the Primary capacity ceiling.
- Pinning recent writers to the Primary for a few seconds eliminates stale reads at the cost of Primary load.
When proposing read replicas, immediately address replication lag: "I route reads from a user who just wrote to the Primary for five seconds, then fall back to replicas." Mention failover via Patroni or Orchestrator promoting the highest-LSN replica, and state clearly that replicas scale reads and availability, never writes.
Linear read scaling and instant standby failover versus unavoidable stale reads and a single-node write bottleneck.