Read replicas
Copy the database to followers that serve reads, so read traffic scales out while one primary takes the writes.
A read replica is a copy of the primary database that answers queries but accepts no writes.
Use it when#
Reads far outnumber writes, and the primary's CPU is mostly read queries.
Reports or search jobs slow down the queries users wait for.
Some pages can tolerate data that is a moment old.
How it works#
The primary streams its changes to each replica, which applies them in order. The app sends writes to the primary and spreads reads across replicas. Three replicas can serve roughly three times the read volume, while the primary keeps its full capacity for writes.
Replication is usually asynchronous, so a replica trails the primary by some milliseconds, and by minutes if it falls behind. A user who saves a profile and reloads can read the old one. The usual repair is read-your-writes: send a user's reads to the primary for a short time after they write.
What it costs#
You buy stale reads and a routing rule in exchange for read capacity. Writes do not scale at all, so a write-heavy load needs sharding, not more replicas. Each replica also repeats every write, so replicas fall behind first when the write rate climbs.
In Quorum#
Place a Read Replica beside the Database and link the App Server to both, after researching Read replicas. Reads go to either, and writes go to the primary only. Synchronous replication is an option that makes every write wait for the replica, and it needs Synchronous replication.
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | small | Small gives the app two vCPUs, enough to run code while the data tier does its own work. |
| App Server | Read-your-writes routing | On | Reads that follow a user's own write go to the primary, so a user who saves and reloads rarely sees the old copy. |
| Database | Instance size | small | Small gives the Database two vCPUs, so the figures below reflect the Cache and not a starved Database. |
| Read Replica | Synchronous replication | Off | Off means the replica applies changes after the primary commits, so writes stay fast and a read can be a moment stale. |
| Read Replica | Instance size | small | Match the primary so each copy takes an equal share of the reads. |
Research this Design needs: Read replicas, Read-your-writes routing.
Watch for the Replication lag and Stale reads incidents. Read-your-writes routing is the fix, and Scale the database puts it in order. The glossary defines read replicas and replication lag.