Read replicas: the cost-versus-performance math
A read replica adds a full instance cost to offload reads and improve read latency, but it does not help writes and adds replication lag. Knowing when a replica pays off, versus caching or a bigger primary, is the decision. Here is the framework.
Quick answer
A read replica adds a full instance cost to offload read traffic and improve read latency and availability, but it does nothing for writes and introduces replication lag. Add one when reads dominate and the primary is read-bound; prefer caching for repeated reads (cheaper) and a bigger primary when writes are the bottleneck.
Read replicas are the default answer to a slow database, and often the wrong one. A replica is a full second instance you pay for around the clock, and it only helps a specific problem: too much read traffic for the primary. Diagnosing that the problem is reads, not writes or repeated queries, is what makes the spend pay off.
What a replica costs and buys
A replica roughly adds the cost of another database instance, plus replication data transfer. In return it offloads read queries from the primary, improves read latency by spreading load, and provides a failover or promotion target. It does not improve write throughput, since all writes still go to the primary, and reads from the replica can be slightly stale due to replication lag.
When a replica is the right spend
| Symptom | Better lever |
|---|---|
| Primary is read-bound, reads dominate | Read replica |
| Same rows read repeatedly | Caching (cheaper) |
| Writes are the bottleneck | Bigger primary or sharding |
| Occasional slow queries | Indexing and query tuning |
If the same rows are read over and over, a cache deflects those reads for far less than a replica, and with lower latency. If writes are the bottleneck, a replica does not help at all and you need a larger primary or a different data model.
The decision
Confirm the primary is genuinely read-bound before adding a replica. Try indexing, query tuning, and caching first, since they are cheaper and often sufficient. Add a replica when reads truly dominate and you have exhausted the cheaper levers, and remember it also buys availability, which may justify it on its own. It is the same cost-versus-performance discipline as optimizing p95 and cost: spend on the lever that fixes your actual bottleneck.
FAQ
When should I add a read replica?
When the primary database is genuinely read-bound, reads dominate the workload, and you have exhausted cheaper levers like indexing, query tuning, and caching. A replica offloads reads and adds availability, but it costs a full extra instance and does not help writes.
Does a read replica improve write performance?
No. All writes still go to the primary, so a read replica does nothing for write throughput. If writes are the bottleneck, you need a larger primary, better data modeling, or sharding, not a replica.
Read replica or caching for read scaling?
For repeated reads of the same data, caching is usually cheaper and lower-latency than a replica, because it deflects reads entirely for the cost of a cache rather than a full database instance. Use a replica when reads are diverse and genuinely exceed the primary's capacity.
What does a read replica cost?
Roughly the cost of another database instance of the same class, plus replication data transfer. Because it runs around the clock, it is a significant, ongoing cost, which is why confirming reads are the bottleneck first matters.
What is the downside of read replicas besides cost?
Replication lag: reads from a replica can be slightly stale, so read-after-write consistency needs care. There is also operational complexity in routing reads to replicas and writes to the primary. These are reasons to prefer caching or tuning when they suffice.
Does C3X estimate read replica cost?
C3X prices your database instances, including replicas, from your Terraform, so the cost of adding a replica appears before deploy. Whether it is the right lever depends on your read-versus-write profile, which you assess from usage.
What to do next
Price a replica before you add it. C3X reads your Terraform and prices your database and the rest of your stack against a live catalog. Start with the quickstart.
Related posts
- Database indexing: the cost-performance trade you control with SQL
The right index turns a full scan into a fast lookup, cutting both query latency and the compute or I/O you pay for. But every index adds write overhead and storage. Here is how indexing trades cost against performance and how to get it right.
- Read replica or cache: which one actually costs less per read
A read replica is a full copy of your database with a full copy of its price. A cache node is a fraction of that. The choice comes down to hit ratio, data freshness, and how many distinct queries you are serving. Here is the cost-per-read math.
- RDS read replica cost: scaling reads and what it adds
Each RDS read replica is a full additional instance with its own compute and storage cost, plus data transfer for cross-region replicas. Here is how read replica pricing works and how to scale reads without overpaying.
- Event-driven vs polling: the cost of asking versus being told
Polling burns compute and requests asking for changes that usually have not happened; event-driven architectures do work only when something occurs. For infrequent events, event-driven is dramatically cheaper. Here is the cost tradeoff.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.