Cache the DB they said. Here's when that triples the bill

Published October 23, 2026

“Just put Redis in front of it” is the sentence that launches a second database bill. The “it” is usually a database that was doing fine, and the cache node costs 73% to 91% as much as the database it is caching.

These three services bill in different dimensions, and that is the whole story. DynamoDB charges per request unit, so a quiet table costs almost nothing. RDS charges for a box, plus storage and IOPS. ElastiCache charges for another box, which you add on top of the database you were caching. Pick the wrong tier of scale and you pay for a cache that could have been the database.

Everything below is us-east-1, on-demand, from our dataset. No Savings Plans, no reserved terms, no “call your account manager” column.

The four prices that decide everything

DynamoDB on-demand is the only one that goes to zero at low traffic, and the only one that charges for every request. That single asymmetry sets up every crossing point below.

Provisioned beats on-demand above 29% utilization

Settle DynamoDB’s own crossover before comparing it to anything else. A provisioned read capacity unit costs $0.0949 a month. One sustained read per second on on-demand burns 2,629,746 read units a month, which at $0.125 per million is $0.33. The same read costs 3.46x more metered than provisioned, and writes match to the decimal.

So provisioned wins whenever average read capacity runs above 29% of what you have provisioned. It is a division problem, not a rule of thumb: $0.0949 / $0.33 = 28.9%. Below that, on-demand wins because you pay only for what you used. Above it, you are paying a 3.5x tax on every sustained unit, and the fix is a console toggle.

The catch is burstiness. On-demand prices a week averaging 100 reads/sec identically whether it runs flat or spikes to 1,000 with 90% dead air, because the meter is per request. Provisioned capacity prices to the peak. The 29% only holds if you can keep capacity matched to load, and with autoscaling lagging a spiky workload the two modes converge.

DynamoDB and RDS cross at 27 reads/sec

For a read-heavy lookup table, the fairest comparison is the one RDS forces: its storage minimum is 20 GB, so both sides get 20 GB.

The $13.98 RDS floor is the db.t4g.micro MySQL box at $11.68 a month plus $2.30 of 20 GB gp3. DynamoDB’s storage floor for the same 20 GB is $5, and reads stack on top at $0.33 per sustained request per second.

The lines cross at about 27 reads/sec, or 2.4 million lookups a day. Below that, DynamoDB on-demand is cheaper, because a mostly idle table costs $5 of storage while a micro RDS instance costs $13.98 whether or not anyone reads it. Above it, the always-on box gets cheaper per lookup, by a lot at 1,000 reads/sec: $14.49 for provisioned DynamoDB against $333.72 on-demand. The only thing between your traffic and that $13.98 bill is whether a t4g.micro can serve it, and it cannot. A t4g.micro is not a 1,000 reads/sec box. Substitute a db.m5.large at $124.83/month or a db.m5.xlarge at $249.66 and the crossing moves, but the shape does not: DynamoDB prices per request, RDS prices per box, and the box wins once the requests are steady.

Two details tilt small-scale DynamoDB further. Eventually-consistent reads cost half a unit, which doubles the RDS crossover to roughly 55 reads/sec if your lookups tolerate it. And DynamoDB storage at $0.25/GB-mo is more than twice RDS’s $0.115, so a 100 GB lookup table is $25 of DynamoDB storage before the first request arrives.

The cache node is a second database bill

ElastiCache and RDS price the same way, because they are both hardware boxes. AWS prices a cache node at nearly the hourly rate of an RDS instance of the same size.

The cheapest possible caching stack is a db.t4g.micro MySQL (or PostgreSQL, same $11.68) behind a cache.t4g.micro: $21.02 a month with a Valkey cache, $23.36 with the equivalent Redis or Memcached node. You have nearly doubled the bill, and the cache is doing nothing the micro database was not already doing in its 1 GiB of RAM.

Go one size up and it gets worse. An m5.large cache in front of an m5.large database moves monthly compute from $124.83 to $215.93 on Valkey or $238.71 on Redis, a 1.7x to 1.9x multiplier. The cache costs 73% to 91% as much as the database it is caching.

Caching earns its keep when it lets you buy a smaller database than the traffic would otherwise force. The upgrade from db.m5.large to db.m5.xlarge is $124.83 a month; an entire cache.t4g.micro Valkey node is $9.34. If your working set fits in the cache and the database’s only job is to refill it, the cache costs a fraction of the skipped upgrade. Under a few hundred sustained reads/sec there is no upgrade to skip, and “just cache it” is a pure cost increase with better latency.

What to do

• Under about 27 reads/sec, spiky or idle: DynamoDB on-demand. Storage plus nothing else.
• Steady reads between 27/sec and the box’s ceiling: RDS, and keep that traffic off on-demand DynamoDB, where it pays the 3.5x tax.
• Sustained reads past a few hundred/sec, or a small hot working set: provision DynamoDB above 29% utilization, or put a cache node in front of the smallest database that can refill it.
• A cache node that does not skip a database class: do not. It is a second database bill for zero marginal capacity.

The one number to remember is 29%: on-demand is $0.33 per sustained read per second and provisioned is $0.0949 per RCU, and that 3.46x gap is the whole argument for provisioning.

Every figure comes from the per-region tables in our databases section. The DynamoDB and Valkey pages carry the exact unit prices in every region, and the RDS MySQL and instance pages tell you what the box costs before you add a second one to cache it.