Most production applications read more than they write.

Users browse products, open feeds, refresh dashboards, search orders, and view profiles far more often than they create or update data. A 10:1 read-to-write ratio is common. Some social, media, and catalog systems are much higher.

At first, one database server can handle everything. Eventually, the read traffic starts to compete with writes for CPU, memory, disk I/O, locks, and network bandwidth.

One tempting answer is: "add another database."

That answer only works if you are careful about who is allowed to write. If two independent databases accept writes for the same data, they can disagree. Resolving those conflicts is much harder than scaling reads.

Read replicas solve the easier part of the problem. One primary database stays responsible for writes, one or more copies follow it, and read traffic moves to those copies whenever stale data is acceptable.

The pattern is simple, but the details matter. Read replicas improve read throughput and availability, but they also introduce replication lag, stale reads, routing decisions, and failover concerns.

This chapter explains how read replicas work, where they help, where they hurt, and how experienced teams use them safely.