Read Replica
A copy of your database that handles read queries, reducing load on the primary database. Writes still go to the primary and replicate out.
What is Read Replica?
In short
A read replica is a copy of a database that serves only read queries (SELECT statements), while all writes go to the primary database and stream out to the replicas. It lets you scale read traffic by spreading queries across many machines instead of overloading one server.
What a read replica actually is
Most applications read data far more often than they write it. A typical web app might do 90 reads for every 1 write: loading product pages, showing feeds, rendering profiles. A single database server can only handle so many queries per second before CPU, memory, or disk I/O become the bottleneck.
A read replica solves this by keeping a continuously updated copy of the primary database on a separate server. The primary handles every INSERT, UPDATE, and DELETE. Those changes are then shipped to one or more replicas. Your application sends write queries to the primary and routes read queries to the replicas.
The result is horizontal scaling for reads. If one server handles 5,000 reads per second, adding four replicas gets you roughly 25,000 reads per second without touching the primary. The primary stays free to do the work only it can do: accepting writes.
How replication works under the hood
When you write to the primary, the change is recorded in a log before anything else happens. PostgreSQL calls this the Write-Ahead Log (WAL), MySQL calls it the binary log (binlog). The primary streams this log to each replica, which replays the same operations to stay in sync.
Most setups use asynchronous replication: the primary confirms a write to the application immediately, then sends it to the replicas a moment later. This keeps writes fast, but it creates replication lag. A replica might be 50 milliseconds behind, or several seconds behind under heavy load. During that window a read from the replica returns stale data.
This causes the classic read-your-own-writes problem. A user updates their profile (write goes to primary), the page reloads (read goes to a replica that has not caught up), and they see their old data. The fix is to route reads that must be fresh, like reading right after a write, straight to the primary, and send everything else to replicas.
Synchronous replication exists too: the primary waits for at least one replica to confirm before acking the write. This eliminates data loss on failover but slows down every write, so most systems reserve it for one critical standby and keep the rest async.
When to use them and the trade-offs
Reach for read replicas when your read load is the problem, not your write load. Reporting dashboards, analytics queries, search indexes, and heavy read APIs are good candidates because they tolerate slightly stale data and can be pointed at replicas without affecting the primary.
Read replicas do not help if writes are your bottleneck. Every replica still has to replay every write, so they all carry the same write load as the primary. To scale writes you need sharding or a different database design, not more replicas.
The main costs are stale reads from replication lag, extra money for more servers, and added complexity in your application or proxy layer to route queries correctly. A read replica can also be promoted to become the new primary if the original primary fails, which makes replicas a building block for high availability, not just scaling.
Where it is used in production
Amazon RDS and Aurora
Supports up to 15 read replicas per Aurora cluster, all reading from shared storage so lag is usually under 100 milliseconds.
PostgreSQL
Ships built-in streaming replication over the WAL, with hot standbys that serve read queries while staying ready for failover.
MySQL
Uses binlog-based replication; companies like GitHub run large replica fleets and route reads through a proxy that respects lag.
MongoDB
Replica sets keep secondary nodes in sync with the primary, and a read preference setting lets the driver send reads to secondaries.
Frequently asked questions
- What is the difference between a read replica and a backup?
- A backup is a frozen snapshot taken at a point in time, stored for recovery. A read replica is a live, continuously updated copy you can actually query right now. Backups protect against data loss; read replicas serve traffic.
- Can I write to a read replica?
- No, replicas are read-only by design. Writing to them would break synchronization with the primary. If a replica is promoted to primary during a failover, it then accepts writes, but a normal replica only serves reads.
- What is replication lag and why does it matter?
- Replication lag is how far behind a replica is compared to the primary, usually milliseconds but sometimes seconds under load. It matters because a read from a lagging replica can return stale data, so freshness-critical reads should go to the primary.
- Do read replicas help with write-heavy workloads?
- No. Every replica replays every write, so they all carry the same write load as the primary. Read replicas only scale reads. For write scaling you need sharding or partitioning instead.
- How does my app know which queries go to the replica?
- Either your application code splits reads and writes explicitly, or a proxy like ProxySQL or PgBouncer routes them automatically. A common rule is to send writes and read-after-write queries to the primary and everything else to replicas.
Learn Read Replica hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Read Replica as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
Leader Election
The process of choosing one node in a cluster to coordinate actions. If the leader fails, a new one is elected. Used by Kafka, ZooKeeper, and etcd.
Database
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
Database Partitioning
Dividing a large table into smaller, more manageable pieces while keeping them in the same database. Sharding is partitioning across servers.
Write-Ahead Log
A technique where changes are written to a log before being applied to the database. Ensures durability and crash recovery.
Consistent Hashing
A hashing technique where adding or removing servers only moves a small fraction of keys. Used by Amazon DynamoDB and Cassandra for data distribution.