Your Database Bill Is Climbing Faster Than Your Traffic

Long story short. A memory shortage is repricing the hardware under every cloud database. Conventional DRAM contract prices rose 93% to 98% in a single quarter, and it lands on your bill: a memory-optimized database instance near $386 a month today is on track for $415 to $500 within a year. The instance price moves with the memory market. How many queries each instance answers is up to you, and that sets your cost per query. In a reproducible benchmark, putting Readyset in front of MySQL served 99.94% of reads from cache and cut the cost per million queries by 213×, a gap that holds even after the hardware gets more expensive.

• Memory is surging: conventional DRAM contract prices rose 93% to 98% quarter over quarter in 1Q 2026.
• It reaches your bill: a database instance is on track to cost 7.5% to 30% more within a year, and hosts like OVHcloud (+5% to 10%) and Hetzner (up to 50%) are already repricing.
• The lever you control: Readyset served 99.94% of reads from cache in a measured MySQL benchmark, so the database ran almost none of them.
• The payoff: cost per million reads fell from about $1.36 to $0.0064 on the same instance, 213× cheaper, and the gap survives every projected price increase.

The full market analysis is in our white paper. The AI demand shock, the memory supply squeeze, and the price signals already surfacing in consumer hardware are covered with sources in How the AI Buildout Is Repricing the Rest of Your Infrastructure (free download). This post keeps the context short and goes straight to the database: what the increase does to an instance you run, and a benchmark you can reproduce.

Why a database instance is about to cost more

Memory prices have climbed a lot through 2025 and into 2026. The AI buildout is the trigger: building high bandwidth memory for accelerators eats the wafer capacity that would otherwise make ordinary server memory, so commodity supply tightened while demand kept rising. TrendForce put conventional DRAM contract prices up 93% to 98% quarter over quarter in early 2026,[1] and Counterpoint expects a server memory module to cost about twice as much by the end of 2026 as it did in early 2025.[2] The full demand and supply story, why the AI buildout is doing this and why the database absorbs it first, is in the white paper.

Memory is roughly 20% to 30% of a server's bill of materials,[3] so when it doubles, the hardware a cloud instance amortizes gets more expensive, and providers have started to say so out loud. The German host Hetzner told customers to expect increases of up to 50% from April 2026, pointing straight at DRAM and NAND,[4] and OVHcloud's CEO forecast cloud service prices up 5% to 10% between April and September 2026.[5] The decade of automatic cloud price cuts is over.

Projecting an instance price

Nobody outside a cloud provider's finance team can tell you the exact future price of an instance. What we can do is show the arithmetic transparently, plug in sourced inputs, and let you see the range. The mechanism is simple: memory is roughly 20% to 30% of a server's bill of materials, and memory is the component that is roughly doubling. If that cost passes through to the hardware the cloud amortizes, the instance gets more expensive.

projected $/hr = base $/hr × (1 + memory_share_of_BOM × (dram_multiplier − 1))

We anchor on the AWS r7i.2xlarge (8 vCPU, 64 GiB), which lists at 0.5292 dollars per hour, about 386 dollars a month, from AWS's own published pricing data on 8 July 2026,[6] because a memory optimized instance is the most exposed and the most common shape for a database. Three scenarios, from most conservative to a full pass-through upper bound:

Projected r7i.2xlarge price under sourced pass-through scenarios

Scenario	Basis	$/hour	$/month	Change
Today	observed 2026-07-08	0.5292	386	baseline
Provider forecast	OVHcloud CEO, +7.5% midpoint[5]	0.5689	415	+7.5%
Memory 2×, 25% of BOM	Counterpoint doubling[2]	0.6615	483	+25%
Memory 2×, 30% of BOM	upper bound[3]	0.6880	502	+30%

r7i.2xlarge, dollars per month (730 hours). The +7.5% bar is a cloud provider's own near term forecast; the +25% and +30% bars assume memory roughly doubles and passes proportionally into the hardware the instance amortizes. The pass-through bars are an upper bound, since an instance price also includes power, network, real estate and margin that memory does not move.

Read this as a range, not a prediction. The provider forecast (+7.5%) is the most credible number because it comes from a host pricing its own hardware. The +25% and +30% figures are deliberately an upper bound: they assume the full server memory share flows straight into price. Reality will land between them. The direction, though, is not in question, and it is the opposite of the last ten years.

So a database instance that costs 386 dollars a month today plausibly costs 415 to 500 dollars a month within a year, for the same hardware. If your read traffic is growing at the same time, you feel it twice. One thing stays in your hands while all this happens: how many queries each instance answers. That's where the rest of this goes.

The lever you control: serve more per box

Instance prices move with the memory market. How many queries each instance answers is something you set, by choosing what to cache. A box can get 30% more expensive and still cost less per query, as long as it serves far more reads. That's the case for putting a cache in front of the database.

Readyset is a transparent SQL proxy that speaks the MySQL and Postgres wire protocols. Your application connects to Readyset instead of the database. Reads that you have chosen to cache are served from memory in microseconds; everything else, including all writes, passes straight through to the upstream database. Writes are never cached: they always go straight to the database. In this test we ran Readyset in shallow mode, a time based result cache: a cached read can be a few seconds stale, then Readyset refreshes it from the database when its window expires. That fits the read heavy dashboard and lookup traffic a finance app generates, and tolerates a few seconds of staleness.

How the benchmark was run

The rules for a number that survives scrutiny: identical dataset and query mix on both sides, the same client concurrency, a discarded warmup, three measured runs, and percentiles rather than averages. The full method is below, and it reproduces on any MySQL with the public Readyset image; here is the shape.

Benchmark setup

Control	Value
Upstream database	MySQL 8.0, InnoDB, 4 GiB buffer pool
Cache	readyset:latest-nightly, CACHE_MODE=shallow
Dataset	~2.0M trades, 1.0M transactions, 468k positions, 80k accounts
Query mix	22 finance queries, Zipfian popularity, point lookups + heavy aggregations
Caches created	22 of 22 (CREATE CACHE succeeded on all)
Method	30s warmup discarded, then 3 × 60s measured, median reported
Host	16 vCPU, 24 GiB; MySQL and Readyset share the box (conservative for Readyset)

Same workload, two paths

At 10 concurrent clients (non-saturated), the median of three 60 second runs. The mix includes a handful of heavy aggregations that scan up to two million rows with no cache; those dominate MySQL's time and are exactly what a cache removes.

Path	Throughput (qps)	p50	p99	Cache hit rate
MySQL, direct	107.9	0.45 ms	3,192 ms	n/a
MySQL behind Readyset	22,985	0.34 ms	2.07 ms	99.94%

• 213× more read throughput on the same hardware
• 1,542× lower p99 tail latency (3,192 ms to 2.07 ms)
• ~1,700 : 1 reads served by cache vs reads that reached MySQL, from the 99.94% hit rate

Independently corroborated in Readyset's own metrics: its readyset_query_log_execution_count put the cache hit rate above 99.9% for the run, the same story the load generator saw.

Under real load, the gap widens. When we pushed both sides to 100 concurrent clients, MySQL saturated: the uncached aggregations queued behind each other and drove its p99 to about 55 seconds while it managed roughly 100 queries per second. Readyset held about 59,455 queries per second at a 12 millisecond p99. Over that run, Readyset's query log recorded 12,377,971 cache-served executions against 4,125 that reached MySQL, a 3,001 to 1 ratio. We report the 10 client, non-saturated numbers above as the conservative headline precisely so the comparison cannot be dismissed as "you overloaded the database."

The number that matters: dollars per query

Convert each path's throughput into a unit cost with the instance prices from the projection above: price divided by the queries an instance answers in an hour.

$ per million queries  =  ($/hour × 1,000,000) ÷ (queries_per_second × 3,600)

On the same AWS r7i.2xlarge, the financial read workload cost 1.36 dollars per million queries hitting MySQL directly, versus 0.0064 dollars per million through Readyset. Even if you insist on running a full size MySQL primary behind the cache and count both instances, the blended figure is about 0.013 dollars per million, still about 106 times cheaper. And in practice the primary can be smaller, because Readyset absorbed 99.94% of the reads.

Cost per million read queries, non-saturated (10 clients), by instance

Instance	$/hour	MySQL direct	Via Readyset	Cheaper by
AWS m7i.2xlarge	0.4032	$1.038	$0.00487	213×
AWS r7i.2xlarge	0.5292	$1.362	$0.00640	213×
OCI E5.Flex 8/32	0.1840	$0.474	$0.00222	213×

The ratio is identical across providers because the throughput gap sets it, not the sticker price. Now put the two forces on one chart: the instance price rising from the memory shock, and the cost per query falling from the cache.

Bars are drawn on a log scale because a linear axis cannot show both 1.36 dollars and 0.006 dollars at once, which is the whole story. Readyset running on the most expensive projected hardware (+30%) still costs about 164 times less per query than MySQL does at today's price. A one-third rise in the instance price barely dents a gap that size.

Why this holds even as hardware inflates. A price increase multiplies both columns by the same factor, so 1.3 times a tiny number stays tiny next to 1.3 times a large one. A cheaper instance class won't change that, because the increase scales every instance together. Needing fewer instances for the same reads is what moves the number, and that's what a cache buys.

Caveats, in plain terms

• Shallow caching is eventually consistent. A cached result can be a few seconds stale. Do not cache a read-your-own-writes path with it. It fits dashboards, listings, aggregations and reference lookups, not "show the user the row they just edited."
• This workload is read heavy and includes expensive queries. The large ratios come from a realistic mix where a few heavy aggregations dominate database time. A workload that is only trivial primary key lookups would show a smaller gap, because MySQL is already fast at those.
• The 100 client MySQL number is a saturation number, and we labeled it as such. The headline 213× uses the non-saturated 10 client run.
• The projection is a model, not a forecast. Its inputs are sourced; its pass-through assumption is an upper bound. Treat the range as a range.
• A few sources are secondary. AWS and Oracle prices come from each provider's own pricing data feed and match to the cent. We left Google Cloud out of the comparison entirely, because it does not publish a public machine-readable price and we would not print a cloud price we could get only from trackers. The one place we relied on analyst estimates is GPU street prices, because no vendor list price exists; they are labeled as such.

What I would do next

For the first time in a decade, the hardware under your database is getting more expensive instead of cheaper, and the numbers above trace why. You can't move the DRAM market, so move the part you can reach: how many queries each instance answers. Caching the reads that dominate database time did that here, cutting cost per query by more than two orders of magnitude, and the gap held under every projected price increase.

If I were sizing a database fleet for 2026, I'd measure cost per query first, cache the heaviest repeated reads, and settle instance types last. That's the line on the bill you still control.

Sources

Every figure in this post links here. Prices and forecasts were gathered on 8 July 2026. The wider market analysis, with its own sources, is in the white paper.

1. TrendForce: 1Q26 DRAM contract prices +93 to 98% QoQ, industry revenue ~$97B (Jun 2026)
2. Network World / Counterpoint: 64GB DDR5 RDIMM could double by end-2026 (projection)
3. Memory as ~20 to 30% of server bill of materials (secondary; treat as a range)
4. The Register: Hetzner price increases up to 50% (many services over 30%), effective 1 April 2026, citing higher hardware and operating costs and expecting DRAM and NAND to double · cybernews
5. The Register: OVHcloud CEO forecasts +5 to 10% cloud prices Apr to Sep 2026, blaming RAM/NVMe
6. AWS EC2 On-Demand pricing (official): r7i.2xlarge us-east-1 = $0.5292/hr, about $386/month, from AWS's published pricing data feed (the JSON the pricing page loads), accessed 2026-07-08.

---

Readyset is a wire-compatible caching proxy for MySQL and Postgres. This post is an engineering analysis; the hardware and cloud figures are third-party and linked above, and the Readyset figures are measured, with the method and image digest given above. Prices change; rerun before you quote.