Overview
In a replicated database, read queries can be routed to the primary node or to one of the read replicas. The choice trades guaranteed data freshness for the ability to scale read throughput and reduce load on the write path.
Comparison Diagram
Comparison Table
| Aspect | Primary Reads | Replica Reads |
|---|---|---|
| Read target | Always the single primary node | Any of one or more read replicas |
| Consistency guarantee | Read-your-writes, strongly consistent | Eventual consistency, may lag behind writes |
| Replication lag exposure | None, reads the current write state directly | Exposed to lag, from milliseconds to seconds |
| Contention with writes | Reads compete with writes for CPU, locks, and I/O | Writes on primary don’t directly compete with replica reads |
| Read throughput scaling | Bounded by single node capacity | Scales horizontally by adding more replicas |
| Latency profile | Consistent, no wait for replication to catch up | Can be lower if replica is geographically closer, but variable under lag |
| Failover behavior | Node failure requires promotion and brief write/read outage | Load balancer can reroute to another healthy replica |
| Typical use case | Financial transactions, read-after-write flows, admin views | Analytics, reporting, public APIs, dashboards |
Key Differences
- Primary reads guarantee read-your-writes consistency; replica reads may return stale data due to lag.
- Replica reads scale horizontally by adding read replicas; primary reads are bottlenecked by a single node.
- Primary reads compete with write traffic for resources; replica reads isolate read load via replication.
- Replication lag on replicas ranges from milliseconds to seconds depending on network and write volume.
- Failover on the primary causes brief unavailability; replica failures are masked by load balancing across peers.
When to Use Each
Primary Reads
- Read-after-write flows: A user updating their profile must immediately see the new value, which only the primary guarantees.
- Financial transactions: Balance checks before a transfer need the current committed state to avoid double-spend or overdraft.
- Admin and audit views: Operators reviewing recent changes need certainty that no pending write is missing from the result.
Replica Reads
- Analytics and reporting: Aggregating historical data tolerates a few seconds of lag and benefits from offloading the primary.
- Public read-heavy APIs: High request volume for content like catalogs or feeds scales better by spreading reads across replicas.
- Geographically distributed reads: A replica placed near end users reduces network latency even if the data is briefly stale.