A read replica is a read-only copy of a primary database that is kept up to date by replication and accepts queries but not writes. In database replication, read replicas are used to scale read traffic horizontally, isolate reporting and analytics from the transactional workload, and place data closer to users in other regions.
Read replicas belong to the primary-replica topology: all writes go to one primary server, which ships its changes to one or more replicas. Because replication is usually asynchronous, a replica can trail the primary by a short interval called replication lag, and every design that uses read replicas must decide how much staleness each query can tolerate.
How a read replica stays in sync
A read replica receives a continuous stream of changes from the primary and applies it in the same order. The format of that stream depends on the engine and determines what kind of replica can be built.
| Method | What is shipped | Engines and notes |
|---|---|---|
| Physical streaming replication | Write-ahead log records, byte for byte | PostgreSQL; replica is an exact block-level copy |
| Binary log replication | Row-based or statement-based change events | MySQL and MariaDB; replica can differ in indexes |
| Logical replication | Decoded row changes per table | PostgreSQL publications; selective tables, cross-version |
| Storage-level replication | Shared distributed storage pages | Managed cloud services; replicas share one storage layer |
In physical replication, the replica is a hot standby: it replays WAL records and answers queries at the same time. Conflicts arise when replay needs to remove row versions that a running query still reads; PostgreSQL then either cancels the query or delays replay, controlled by max_standby_streaming_delay and hot_standby_feedback.
Large deployments sometimes use cascading replication, in which a replica streams changes onward to further replicas. This reduces network and CPU load on the primary when there are many replicas or several regions, at the price of additional lag at each hop and a longer chain that must be monitored.
Replication lag and consistency
The central trade-off of a read replica is freshness versus throughput. Asynchronous replicas add no latency to commits on the primary, but a query on the replica may not yet see a change the application has just written.
Typical lag on a healthy network is from a few milliseconds to under a second. It grows to seconds or minutes when the replica is undersized, when a long query blocks replay, when a large batch job writes faster than one apply thread can follow, or when the network between regions is congested. Lag must be monitored continuously, for example through pg_stat_replication on PostgreSQL or Seconds_Behind_Source on MySQL.
| Mode | Commit latency on primary | Freshness of replica reads |
|---|---|---|
| Asynchronous | Unaffected | May be stale by the current lag |
| Semi-synchronous | Waits for receipt by one replica | Received but not always applied |
| Synchronous with remote apply | Waits until the replica applies the change | Read-your-writes on that replica |
Applications that need read-your-writes consistency usually route a user’s reads to the primary for a short window after that user writes, or pass a log position to the replica and wait until it has replayed that far.
Read replicas compared with related replication roles
The same physical server can play different roles, and the names are often used loosely. The distinction is what the copy is for, not how it is built.
| Concept | Primary purpose | Serves queries |
|---|---|---|
| Read replica | Scale and isolate read traffic | Yes, read-only |
| Standby for failover | Take over if the primary fails | Optional; often idle |
| Multi-primary cluster member | Accept writes on several nodes | Yes, reads and writes |
| Backup or snapshot | Recovery to a past state | No |
| Cache such as Redis | Serve hot keys in memory | Yes, but not full SQL |
A read replica is not a backup. A destructive statement such as an accidental DELETE replicates within moments, so replicas protect against server loss but not against human or application error. A delayed replica, which deliberately applies changes an hour or more late, is the exception that provides a short recovery window.
Routing queries to read replicas
Read replicas help only when read queries are actually sent to them. Routing happens in the application, in a driver that supports read-write splitting, or in a proxy such as ProxySQL, HAProxy or Pgpool-II.
- Send to replicas: reports, dashboards, search pages, exports and other reads that tolerate a little staleness.
- Keep on the primary: reads inside a write transaction, reads immediately after a write, and checks that guard money or inventory.
- Balance and health-check: remove a replica from the pool when its lag exceeds a threshold such as 5 or 30 seconds.
- Size replicas like the primary when they may be promoted, because an undersized replica becomes an undersized primary.
Read replicas do not scale write throughput. Every replica must apply every write, so a write-bound system needs partitioning, sharding or a faster primary instead.
Replicas also carry operational costs that are easy to underestimate. Each one needs the same storage as the primary, its own monitoring and patching, and schema changes must replicate cleanly; a long ALTER TABLE on the primary can block replay on every replica until it finishes.
A plain-language summary
A read replica is a second copy of a database that only answers questions. The main database handles all the changes. It then sends those changes to the copy, which follows along a moment later.
It works like a library that keeps extra copies of a popular book in other reading rooms. More people can read at the same time. The catch is that a copy may be a few seconds behind the original.
An example from practice
A regional news website runs on one MySQL primary that handles comments, logins and editorial updates. Breaking stories cause traffic spikes, and heavy analytics queries from the newsroom dashboard slowed article pages at exactly the wrong moments.
The team added two read replicas. Article pages and search now read from the replicas through a proxy, the analytics dashboard uses a third replica of its own, and logins and comment posting stay on the primary. A health check removes any replica lagging more than 10 seconds. During the next major story, CPU on the primary stayed below 40%, page loads remained steady, and readers saw new comments within about a second, which the editors judged acceptable.