Read replicas: the cost-versus-performance math

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.