Read replicas
A read replica takes read load off the primary. 10,000 reads/s can spread over replicas, but each replica must also apply all 1,000 writes/s. The lag between the primary and a replica must stay below 1 s.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | One server does all work | Reads spread over 3 servers |
|---|---|---|---|
| p99 latency | under 100 ms | 4.2 s Fail | 25 ms Pass |
| Replica lag | under 1 s | 0 s Pass | 0.1 s Pass |
| Monthly cost | 8 USD/mo | 24 USD/mo | |
| Error rate | 3.8% | 0% |
Key numbers
| Number | Value |
|---|---|
| Reads per second, one database vCPU | 15,000 reads/s |
| Writes per second, one database vCPU | 2,500 writes/s |
| Default replica lag | 0.1 s |
Quorum 2 of 3 · commit 9.0 ms
How it works
Most databases serve many more reads than writes. One server must do all the writes, because two writers would conflict. But reads can run on copies. A read replica receives every change from the primary and keeps its own copy of the data. Clients read from the replicas, and the primary has more time for writes.
In the mini board the database receives 10,000 reads/s and 1,000 writes/s. One server must do both, and p99 passes the 100 ms limit. Three servers share the reads, so each one serves about 3,300 reads/s.
There are two limits. First, each replica must still apply every write. At 1,000 writes/s each replica does that work too, so adding replicas does not reduce the write work on each of them. A workload with many writes gains less. Second, a copy is a little behind. A change takes time to reach a replica, and the replica lag must stay below 1 s here. A user who writes and then reads from a replica can see old data.
Send reads that must be fresh to the primary. Send the rest to the replicas. Watch the lag, and take a replica out of rotation when it falls too far behind.
In the levels you add replicas and check p99 and the replica lag.