What Is a Read Replica? Database Scaling Explained

A read replica is a copy of a database that stays continuously synced with a primary (or “leader”) instance and serves read-only queries. Instead of every SELECT hitting the same server that handles writes, an application can route reads to one or more replicas, freeing the primary to focus on writes and reducing the load any single machine has to absorb.

Read replicas are one of the simplest, most common ways to scale a database horizontally without touching the application’s data model, which is why nearly every managed database service — Postgres, MySQL, and their cloud equivalents — offers them as a built-in feature.

How replication actually works

The primary database writes every change to a durable log before applying it — the same write-ahead log that protects against crashes. Replicas don’t reprocess your application’s queries; instead, they stream that log from the primary and replay the changes locally, keeping their own copy of the data in near-lockstep.

There are two broad flavors:

• Physical (or streaming) replication ships the low-level log records and replays them byte-for-byte. It’s fast and exact but ties the replica to the same database engine and version as the primary.
• Logical replication decodes changes into row-level operations (insert, update, delete) and applies them as SQL-equivalent statements. It’s more flexible — replicas can run different versions, filter specific tables, or even feed a different storage engine — at some cost in throughput.

Most managed services default to physical replication for standard read replicas and offer logical replication as an option when you need more control over what gets copied.

Replication lag is the catch

Replication is asynchronous by default: the primary acknowledges a write and moves on without waiting for replicas to catch up. That gap between “write committed on the primary” and “write visible on the replica” is replication lag, and it’s the central trade-off of this whole pattern.

Lag is usually milliseconds under normal load, but it can spike under heavy write traffic, long-running transactions, or network issues between regions. The practical consequence: a user who just updated their profile and immediately reloads the page might read a replica that hasn’t caught up yet, and see stale data. This is a classic eventual consistency trade-off, not a bug — you’re exchanging strict consistency for horizontal read capacity.

Some engines support synchronous replication, where the primary waits for at least one replica to confirm the write before acknowledging it. That eliminates lag for the synced replica but adds latency to every write and makes the primary’s availability depend on the replica’s. Most systems reserve synchronous replication for a small number of critical replicas and keep the rest asynchronous.

Read replicas vs sharding

It’s worth distinguishing replicas from database sharding, since both come up under “scaling a database” but solve different problems.

	Read replicas	Sharding
Copies of data	Full copy on each replica	Each shard holds a subset
Scales	Read throughput	Both read and write throughput
Write path	All writes go to one primary	Writes distributed across shards
Complexity added	Routing reads, handling lag	Routing by shard key, cross-shard queries
Typical trigger	Read-heavy workload, single write bottleneck fine	Write volume or data size exceeds one machine

In practice, teams usually add read replicas long before they need to shard. Replicas require no changes to your schema or query patterns beyond deciding which queries can tolerate slightly stale data; sharding is a more invasive change that touches how data is modeled and queried.

Common uses beyond load balancing

• Analytics and reporting. Point dashboards and long-running aggregate queries at a dedicated replica so they don’t compete with production traffic on the primary. A slow analytical query on the primary can hold locks and starve real user requests; isolating it to a replica contains the damage.
• Geographic distribution. Placing replicas closer to users in different regions cuts read latency, similar in spirit to how a CDN caches static assets near the edge — except here it’s live query results, not static files.
• High availability and failover. Many managed database services can promote a replica to primary automatically if the original primary fails, minimizing downtime. This requires careful handling: in-flight writes to the old primary that hadn’t yet replicated can be lost in the failover, so systems that can’t tolerate any data loss need synchronous replication on at least one replica.
• Backup isolation. Running backups against a replica avoids the I/O overhead of a full backup competing with live write traffic on the primary.

Application-level considerations

Adding replicas isn’t transparent to your application — you need a strategy for routing queries:

1. Connection routing. Most setups use a proxy or driver-level logic to send writes to the primary and reads to replicas. This is often handled by connection pooling middleware sitting in front of the database.
2. Read-your-writes consistency. If a user needs to see their own write immediately, route that specific read to the primary (or a synchronous replica) rather than risk hitting a lagging replica.
3. Monitoring lag. Track replication lag as a first-class metric. A replica that falls far behind under load is a signal to add more replicas, reduce write volume, or investigate a slow query holding things up.

The takeaway

A read replica is a synced, read-only copy of a database that offloads query traffic from the primary, and it’s usually the first lever teams pull when a database becomes a read bottleneck. The trade-off is replication lag: reads from a replica can be milliseconds to seconds behind the primary, so route anything requiring strict freshness — like a user reading their own just-made write — back to the primary. For write-heavy scaling beyond what a single primary can handle, replicas alone won’t help; that’s when sharding enters the picture.