The read wall
Almost every web app reads far more than it writes: one user posts a comment, thousands load the page. Sooner or later the single database instance saturates, and the first instinct, renting a bigger one, has a doubling price at every step (lesson 3-1's catalog) and a hard ceiling at the top of the catalog. Engineers hit this wall at real companies constantly, and this lesson is the standard first answer.
A read replica is a second database instance that RDS keeps as a continuously-updated copy of the primary, fed by replication: every change to the primary is shipped to the replica and re-applied there. The replica gets its own endpoint and serves read queries only; all writes still go to the one primary, which is what keeps the data consistent.
Your app then splits its traffic: writes and must-be-fresh reads to the primary's endpoint, everything else (dashboards, search pages, reports) to the replicas. RDS supports several replicas per primary, and you can add them without downtime.
Code exercise · bash
The sizing arithmetic that motivates replicas. An app pushes 900 reads and 100 writes per second at a database instance that handles about 400 queries per second. Run it, and note the shape of the fix: the writes were never the problem.
Lag, and replica versus standby
Replication to read replicas is asynchronous: the primary confirms a write to your app first and ships it to replicas a moment later. That gap is replication lag, usually well under a second, sometimes seconds under load. Design around it: any read that must reflect a write the same user just made goes to the primary.
Do not confuse a replica with the Multi-AZ standby from lesson 6-1 — they answer different questions:
| Multi-AZ standby | read replica | |
|---|---|---|
| exists for | availability (surviving an AZ failure) | read scale |
| serves queries? | no, idle until promoted | yes, reads |
| replication | synchronous (no lag) | asynchronous (lag) |
Production databases commonly run both. Replicas have one more career: a replica can be promoted to a standalone primary, and a replica in another region doubles as a disaster-recovery copy and a low-latency read point for far-away users (lesson 1-2).
Quiz
A user saves a new profile photo, the app writes it to the primary, and the very next page load reads from a replica and shows the OLD photo. What happened?
Problem
Your analytics dashboard's heavy SELECT queries are overloading the primary. A teammate says: "we already pay for Multi-AZ, just point the dashboard at the standby." That will not work, because the standby serves no queries. What should the dashboard read from instead? (Two words.)