Most applications read data far more often than they write it — dashboards, product pages, and reporting queries typically outnumber inserts and updates by an order of magnitude. A read replica is a continuously updated, read-only copy of the primary database that absorbs that read traffic, leaving the primary's capacity free for writes. Because a replica holds a full copy rather than a slice of the data, adding one requires no changes to your schema or your application's write path — you only need to decide which queries are safe to route away from the primary. For the common case where reads dominate, replicas solve the scaling problem with far less complexity than sharding. The tradeoff is replication lag: a replica is asynchronously updated, so it is always a little behind.
What changed in 2026
- Failover automation matured. Patroni, RDS Multi-AZ, and Aurora reader endpoints make replica promotion close to automatic when a primary fails, instead of a manual, high-stress runbook.
- Managed providers made replicas a checkbox. Neon, Supabase, and PlanetScale now offer read replicas as a plan setting rather than a multi-week infrastructure project.
- Read-your-writes handling became a standard library feature. ORMs and edge frameworks increasingly pin a session to the primary right after that session's own write, automatically.
- Multi-region replicas got cheaper and faster. Serving reads from the replica nearest the user, while keeping a single write primary, is now a routine pattern rather than a specialist one.
How a replica actually stays current
A primary writes every change to a write-ahead log before applying it to its own data files. Streaming replication ships that log to each replica, which replays it to stay in sync. This happens asynchronously by default: the primary commits a transaction and returns success to the client without waiting for any replica to confirm it received the change. That is what makes replicas cheap to add and fast for the primary, and it is also exactly why replica lag exists — under heavy write load, or with a replica in a distant region, that lag can grow from milliseconds to seconds or more. Synchronous replication removes the lag by waiting for replica acknowledgment before committing, at the cost of added write latency and a replica outage blocking writes entirely.
Deciding what to route to a replica
| Query type |
Route to |
Why |
| Dashboards, analytics, reporting |
Replica |
Tolerant of a few seconds of lag |
| A read immediately after this session's own write |
Primary |
Avoids showing the user stale data they just changed |
| Search, browsing, product listings |
Replica |
Freshness to the second rarely matters here |
| Balance check before charging a payment method |
Primary |
Correctness matters more than shaving off load |
A simple, durable rule: anything where staleness would confuse or cost the user money goes to the primary; everything else is a replica candidate.
Common mistakes
Reading your own write from a replica. A user updates their profile, the page reloads, and it hits a replica that has not caught up yet, showing the old value. Pin that specific read to the primary for a short window after the write, or read from the primary for anything in the same request.
Treating replica lag as always negligible. Lag is often single-digit milliseconds — until a bulk import or a spike in write traffic pushes it to seconds or more. Monitor lag explicitly; don't assume it.
Routing a write to what you thought was the primary connection string. A misconfigured service pointed at a read-replica endpoint will fail loudly on the first write, or silently if the replica happens to accept writes in a misconfigured setup — check this in every new service's config, not just once.
Using replicas to paper over missing indexes. Adding replicas to handle load from an unindexed query multiplies the wasted work across every replica instead of fixing it once at the source.
FAQ
What is the difference between synchronous and asynchronous replication?
Synchronous replication waits for a replica to confirm before the primary commits, guaranteeing no data loss on failover at the cost of latency. Asynchronous replication commits immediately and ships changes after, which is faster but can lose the most recent transactions if the primary fails before they replicate.
How many read replicas can I add?
There is no hard limit for most managed databases, but each replica adds a small amount of WAL-streaming overhead on the primary. Most workloads are comfortable with two to five replicas before considering other scaling strategies.
Do read replicas help with write-heavy workloads?
No. Replicas only add read capacity; every write still goes through the single primary. For write scaling, see database sharding explained for 2026.
What happens during replica promotion?
When a primary fails, a replica is promoted to become the new primary. Automated tools handle this in seconds to a minute; application connections need to reconnect to the new primary endpoint, which is usually handled by a proxy or DNS-based endpoint.
Where to go next
For the write-side counterpart to this problem, read database sharding explained for 2026, see PgBouncer explained for 2026 for routing reads and writes through a pooler efficiently, and use how to pick a database in 2026 to decide if replicas alone will be enough for your workload.