Read Replica
A read-only copy of an RDS or Aurora database that handles SELECT queries. Uses asynchronous replication from the primary — there may be seconds of lag. Scales read throughput, not high availability.
What is a Read Replica
A Read Replica is an additional database instance that continuously receives changes from the primary via asynchronous replication. Your application sends SELECT queries to the replica, keeping the primary free for writes.
Without Read Replica: All traffic → Primary DB Heavy reporting query running at 2 PM → slows all writes and reads With Read Replica: Writes + critical reads → Primary Reporting queries, analytics → Read Replica Primary is completely unaffected by reporting loadHow Replication Works
Primary DB writes data ↓Replication stream (asynchronous) ↓Read Replica applies the changesTypical lag: milliseconds to a few seconds ASYNC means: replica may be slightly behind primaryA write on primary may not be immediately visible on replicaThis is acceptable for reporting — not for reading your own writesRead Replica Limits
Standard RDS: up to 5 Read Replicas per primaryAurora: up to 15 Read Replicas per clusterCross-Region Read Replicas
Create a replica in ap-southeast-1 from a primary in ap-south-1Southeast Asian users read from nearby replica — lower latencyIf primary region fails: promote replica to standalone primaryPromotion
A Read Replica can be promoted to a standalone database — becoming an independent primary. This is NOT automatic. You trigger it manually.
Promotion use case: Primary has a major issue Manually promote a read replica to become the new primary Update application connection string to new endpointRead Replica vs Multi-AZ Standby
| Read Replica | Multi-AZ Standby | |
|---|---|---|
| Purpose | Read scaling | Disaster recovery |
| Replication | ASYNC (may lag) | SYNC (always identical) |
| Serves traffic | Yes — read queries | No — waits silently |
| Failover | Manual promotion | Automatic in 60-120s |
RememberA Read Replica is for scaling reads. A Multi-AZ standby is for surviving failures. They solve completely different problems. Do not confuse them — your system needs both in production.
Frequently Asked Questions
Why can't you rely on a Read Replica for failover the way you would with Multi-AZ?
A Read Replica uses asynchronous replication, so there's typically a small lag — often sub-second but capable of growing to seconds under heavy write load — meaning a promoted replica can lose the most recent transactions. Multi-AZ, by contrast, uses synchronous replication specifically for durability and automatic failover with no data loss. Read Replicas exist to horizontally scale read traffic off the primary; RDS does support manually promoting one to a standalone primary, but that's a deliberate disaster-recovery action, not automatic failover.
What's a common mistake when pointing an application at a Read Replica?
Sending a write immediately followed by a read of that same row to a Read Replica, and getting stale or missing data because replication hasn't caught up yet — a classic read-your-own-writes bug. The usual fix is routing anything that must reflect a just-made write back to the primary, and only sending genuinely read-tolerant traffic (dashboards, reports, analytics queries) to replicas.