Most production applications read far more than they write. At first, one database server can handle everything. Later, read traffic starts competing with writes for CPU, memory, disk, locks, and network bandwidth.

One fix is to add another database, but only if you are careful about who is allowed to write. If two separate databases accept writes for the same data, they can disagree. Fixing those disagreements is much harder than scaling reads.

Read replicas solve one specific problem: scaling reads. One primary database handles writes. One or more copies follow it. Read traffic can move to those copies when slightly stale data is acceptable.

The pattern is simple, but the details matter. Replicas introduce lag, stale reads, routing choices, and failover work. This chapter explains how read replicas work, where they help, where they hurt, and how to use them safely.