Read Replicas

Read replicas are read-only copies of a primary database, kept up to date via asynchronous replication, that let an application distribute read-heavy query load across multiple database instances instead of sending every query to a single primary. They’re one of the most common first steps teams take when a database becomes a scaling bottleneck.

How They Work

All write operations (inserts, updates, deletes) go to the primary database instance. Changes are then streamed asynchronously to one or more replica instances, which apply those same changes to their own copy of the data. Applications route read-only queries — the kind that don’t need to see the absolute latest write — to the replicas, freeing the primary to handle writes and any reads that require strict consistency with the latest data.

The Replication Lag Tradeoff

Because replication is asynchronous, replicas are not guaranteed to be perfectly current with the primary — there’s a small delay, called replication lag, between a write landing on the primary and that same write becoming visible on a replica. This makes read replicas well suited to workloads that can tolerate slightly stale reads (a product listing page, an analytics dashboard) but poorly suited to reads that require absolute consistency with the most recent write (checking an account balance immediately after a transaction), which should generally still be routed to the primary.

Where They’re Used

Nearly every major managed database service — Amazon RDS, Cloud SQL, Azure Database — supports read replicas as a built-in feature, and they’re a standard early scaling technique for read-heavy applications before reaching for more involved solutions like sharding or a dedicated caching layer.

Read Replicas and Eventual Consistency in Application Design

Applications using read replicas need to be explicitly designed around the possibility of stale reads, since a query hitting a replica immediately after a related write on the primary might not yet reflect that write. A common pattern is routing any read that immediately follows a write by the same user back to the primary temporarily (sometimes called “read-your-writes” consistency), while routing all other, less time-sensitive reads to replicas — a hybrid approach that captures most of the scaling benefit of read replicas while avoiding the most user-visible consistency problems that pure replica-only reads could otherwise introduce.

Most managed database services also support automatically promoting a read replica to become the new primary during a failover event, blurring the line between a pure read-scaling replica and a disaster-recovery standby, though the asynchronous replication lag means this promotion path carries a small risk of losing the most recent unreplicated writes compared to a synchronous Multi-AZ failover.