Read Replica
A read replica is a copy of a database that serves read traffic and scales read capacity, at the cost of replication lag.
Definition
A read replica is a secondary database that continuously applies changes from a primary and serves read-only queries. It relieves the primary of read load, allows reads to scale horizontally, and can be promoted to primary on failover. The central tradeoff is replication lag: writes are visible on the primary immediately but on replicas after a delay, so a read-your-writes expectation can be violated unless the application routes or waits appropriately.
Context and scope
Standard scaling approach for read-heavy applications, and for analytics that should not compete with transactional traffic on the primary.
Common misconceptions
- Replicas are always consistent — they lag; a read immediately after a write may not see that write
- More replicas means more write throughput — replicas scale reads; writes still funnel through the primary
- Failover is automatic and lossless — promotion depends on how much of the log the replica had applied and on the failover tooling
Anti-patterns
- Sending every read, including read-after-write, to a replica and wondering why users see stale data
- Running long analytical queries on the primary and calling it "just one query"
- Assuming a promoted replica has all recent writes without measuring the replication lag at failover
Related concepts
Authoritative source
What it is
A read replica maintains a copy of the primary data by applying the same ordered stream of changes — usually the primary write-ahead log. Clients connect to it for read-only queries, offloading the primary. Because replication is asynchronous in the common configuration, the replica is a slightly older view of the data. Synchronous replication reduces the lag but couples write latency to the replica health.
Why it matters
Most applications read far more than they write, so the primary becomes a read bottleneck even though write volume is modest. Replicas add read capacity horizontally and let heavy reporting or search queries run away from transactional traffic. They also provide a warm standby for failover and a natural partitioning of workload by purpose, at the price of eventual consistency on the read path.
How to use it well
Route read-only and tolerance-for-staleness queries to replicas, and keep read-after-write on the primary or use a session that pins to it until the write is known replicated. Monitor replication lag and degrade explicitly when it grows. Cap the number of replicas for write-heavy workloads, since each adds replication overhead on the primary. Test failover, including how much unapplied log is lost, and treat the promoted replica as a recovery point rather than a guarantee.