A read replica is a read-only copy of a database that stays in sync with the primary (writeable) database. It is updated asynchronously — meaning changes in the primary DB are eventually propagated to the replica.
🧠 What Is a Read Replica?
Primary DB handles all writes (INSERT, UPDATE, DELETE)
Read Replica handles read-only queries
Updates are streamed from the primary to the replica (e.g., via binary logs or WAL)
[ Primary DB ]
|
async |
v
[ Read Replica ]
✅ Why Use a Read Replica?
1. Read Scalability
Offload heavy SELECT queries to replicas
Improves performance by reducing load on the primary
2. High Availability
Use replicas as failover targets if the primary goes down
3. Disaster Recovery
Replicas act as live backups — safer than daily snapshots
4. Geographic Distribution
Deploy replicas in different regions to reduce latency for global users
5. Reporting and Analytics
Run expensive reports or BI dashboards on replicas without affecting production
❌ Limitations
Limitation
Description
Eventually consistent
There can be replication lag
Read-only
You cannot modify data on the replica
No automatic failover
Must promote manually (or use orchestration)
Increased complexity
Requires query routing and monitoring
🛠️ Example Use Case (PostgreSQL)
Enable replication on the primary DB.
Set up a replica server using pg_basebackup.
Configure replication via standby.signal and primary_conninfo.