Read replica or cache: which one actually costs less per read

When a primary database starts running hot on reads, two answers present themselves: add a read replica, or put a cache in front. Teams often pick by familiarity rather than by arithmetic, which is a shame, because the cost difference per read served can be an order of magnitude in either direction depending on the access pattern.

The list prices

The critical asymmetry: a read replica carries a full second copy of storage. A 500 GB database replicated once costs $378 for compute plus $57.50 for storage, about $435 per month. The cache carries no storage charge at all, because it holds a working set in memory and forgets the rest.

Cost per read served

Take a workload doing 4,000 reads per second at peak, roughly 10.4 billion reads per month if sustained. A db.r6g.xlarge replica handling that load costs $435 per month, about $0.042 per million reads. A cache.r6g.large easily sustains well over 100,000 operations per second on a single node, so the same 10.4 billion reads through cache cost $150 per month, about $0.014 per million reads, roughly a third of the replica's rate.

But the cache only serves the reads it hits. At an 85 percent hit ratio the remaining 15 percent, about 1.56 billion reads, still land on the primary. If the primary was already sized for writes plus that residual read load, you have avoided the replica entirely and your total incremental cost is $150 instead of $435, a saving of about $285 per month. At a 40 percent hit ratio the residual 60 percent probably still needs the replica, and now you are paying for both: $585 per month for an architecture that a replica alone would have served for $435.

The break-even hit ratio

A simple way to frame it: caching wins when the hit ratio is high enough that the residual read load fits inside the primary's existing headroom. If the primary is at 70 percent CPU with reads contributing 50 points of that, a cache that removes 85 percent of reads takes reads down to roughly 7.5 points, leaving the primary at about 27 percent. That is comfortable. A cache removing 40 percent leaves reads at 30 points, primary at 50 percent, which is survivable but leaves no failover headroom.

Hit ratio is mostly a function of key cardinality and request skew. Session lookups, product catalogs, feature flags, permission checks, and rendered fragments cache beautifully because a small hot set absorbs most traffic. Reporting queries, filtered searches with many parameter combinations, and per-user timelines cache badly because every request is a distinct key. Measure the skew before you buy either option: pull a day of query logs, hash the normalized query plus bound parameters, and count what fraction of requests fall in the top 1,000 keys.

The hidden costs on each side

A cross-AZ read replica also pays data-transfer charges on replication traffic at $0.01 per GB in each direction. A write-heavy database generating 200 GB of WAL per day sends about 6 TB per month to the replica, which at $0.02 per GB round trip is roughly $120 per month of pure transfer. That is a line people forget entirely, and it can be a quarter of the replica's compute cost.

On the cache side, the real expense is engineering time on invalidation. A cache with a 60 second TTL and no explicit invalidation is cheap to build and produces a support ticket every time someone updates a record and does not see the change. A correctly invalidated cache is more code, more tests, and more ways to be subtly wrong.

The practical recommendation

Start with a cache when reads are skewed and staleness of a few seconds is acceptable, because it is the cheaper instrument per read removed and it does not double your storage bill. Add a replica when reads are diverse, when analytical queries need to be isolated from transactional ones, or when you need a second copy for availability reasons anyway. Many mature systems run both, and that is fine as long as the cache is earning its hit ratio.

Whichever you choose, price it from Terraform before you merge so the second storage copy and the cross-AZ replication traffic appear in the estimate rather than on the invoice. Compare node families and replica configurations against the resource catalog, and see read replica cost against performance for the replica-side detail.

FAQ

What to do next

Cost both read-scaling options before you pick one. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.