Read Replicas

What is a read replica?

A read replica is a copy of a database that continuously receives changes from the primary (via WAL streaming or equivalent) and serves read queries, while all writes still go to the primary. It’s usually the first scaling move a growing application makes, because read traffic dominates most workloads: offload reporting, dashboards, and read-heavy endpoints to replicas, and the primary breathes. Managed databases (RDS, Cloud SQL, Aurora) make adding a replica a checkbox.

What replicas do and don’t solve

Replicas scale reads, full stop — and only reads. They do nothing for write scaling (every write still funnels through the one primary; when writes are the bottleneck, you need sharding, not replicas), and they add capacity, not durability guarantees on their own. The defining catch is replication lag: replicas are asynchronously behind the primary by milliseconds to seconds (more under load), which produces the classic bug — a user updates their profile (write → primary), the page reloads (read → replica), and they see the old data because the replica hasn’t caught up. This “read-your-own-writes” violation is the thing every team hits once. Fixes: route a user’s reads to the primary briefly after they write, use synchronous replication for critical paths (at a latency cost), or monitor lag and pull laggy replicas from rotation.

Replicas and failover

Replicas double as standby for high availability: promote a replica to primary when the primary fails, turning a copy into a recovery mechanism. But asynchronous replicas can lose the last few unreplicated writes on promotion, so durability-critical setups keep at least one synchronous replica. And promotion that’s never rehearsed fails at 3 a.m. — failover drills are the difference between a copy and a recovery plan.

What people get wrong

• Expecting write scaling from replicas — they scale reads only; write bottlenecks need sharding or a bigger primary.
• Ignoring replication lag: routing a user’s post-write reads to a lagging replica and serving stale data.
• Replicas as backups — replication faithfully copies your accidental DELETE to every replica; you still need point-in-time backups.

Primary source: Amazon RDS — read replicas