I Priced a RAM Upgrade in July. Six Weeks Later I Cancelled It and Rewrote My Cache Instead.

In July I wrote up what the AI memory crunch costs a one-VPS self-hoster and ended it planning a modest upgrade — more RAM on the box, sometime this quarter, before things got worse. Things got worse. I've cancelled the upgrade, and the way I got to that decision is more useful than the price chart.

The six-week delta

A mainstream 32GB DDR5-6000 kit is running around $392. The same class of kit was $110–140 in Q3 2025. DRAM rose about 95% in Q1 and another 63% in Q2. Analysts estimate AI data centres could absorb roughly 70% of high-end DRAM output this year, and current supply forecasts don't expect meaningful capacity additions until late 2027 or 2028.

Read those together and the conclusion is not "memory is expensive right now." It's that vertical scaling is off the table for a solo self-hoster for roughly two more years. Not painful — unavailable at any price I'd rationally pay. Waiting for a dip is not a strategy when the fabs are sold out until 2028.

The one caveat I'd attach: those percentages come from different trackers measuring different baskets, and the consumer-kit prices people quote on forums move faster than the server DRAM contracts a VPS provider actually signs. My hosting bill hasn't jumped 89%. The direction is unambiguous; the magnitude is not the same everywhere in the stack.

Where my memory was actually going

Before spending money, I did the thing I should have done first and measured. My box runs nginx, Payload, Mastra, n8n, an agent, and a database. I'd assumed the database was the hog. It wasn't close.

# the honest breakdown, once I stopped guessing:
node processes   -> three separate runtimes, three heaps,
                    each sized for a peak that never coincides
db               -> large, but bounded and well-behaved
agent + tooling  -> spiky; the spikes were the whole problem

I wasn't short of memory. I was short of memory for about forty minutes a day, when an agent run overlapped an n8n job. Buying a permanent 32GB to cover a spiky forty minutes is exactly the kind of purchase that feels like engineering and is actually just spending.

What I did instead

Capped the heaps and let the scheduler do its job. Explicit heap ceilings per process and a MemoryMax in the systemd unit for each service. I already had the sandbox units from hardening the agent — adding a memory ceiling was one line in a file I'd already written. Security work paying a performance dividend is rare enough to enjoy.

Stopped the jobs from colliding. The forty bad minutes were two schedules that happened to share a cron slot. Moving one by twenty minutes cost nothing and removed most of the pressure. This is embarrassing to write down and it was the single biggest win.

Cached the things that were being recomputed. The new MCP spec added ttlMs to list results, which meant my server stopped rebuilding the same tool listing on every request. I'd filed that as a token-cost improvement. It's also a memory one.

Moved the spiky work off the box. Not everything — the one-box philosophy still holds — but the occasional heavy agent run is now a hosted API call rather than local inference. In a world where RAM is the scarce resource and API tokens are the abundant one, the arithmetic that made self-hosting inference attractive in 2024 has quietly inverted.

That last one connects to something I noticed writing about GLM-5.3 hitting the same coding score at 50k output tokens instead of 120k. Efficiency gains at the model layer are arriving faster than hardware relief is. If you're capacity-constrained in 2026, the leverage is in what you run, not what you run it on.

The uncomfortable part

None of this is a story about my server. It's a story about a hyperscaler buildout reaching down through four layers of abstraction to change what a hobbyist can afford. I wrote about NVIDIA's water-free data centres as an engineering story about heat. The memory crunch is the same story about a different constraint, and it's the one that reached my invoice first.

If you're weighing whether to start self-hosting right now, the honest advice has shifted since I wrote my pre-flight post: size the box for two years of growth on day one, because topping it up later is now a market-timing decision rather than a purchase. Buy the RAM you'll need in 2027 while it's merely expensive, or design so you never need it.

The verdict

The upgrade is cancelled and the box is running better than it was in July, which tells you the upgrade was never the fix. I bought back headroom with a cron change, four MemoryMax lines, a cache TTL, and one workload moved off-box. Total cost: an evening.

For a decade the reflex answer to a resource-constrained server was to buy more server, and it was usually correct because hardware got cheaper every year. That reflex is now wrong, and will stay wrong until at least 2028. Profile before you buy was always good advice. The memory market just made it mandatory.

Sources

Current kit pricing and the 2025 baseline: TechJournal's record-high roundup and this 17 August shortage update. The ~70%-of-high-end-DRAM estimate and the data-centre allocation mechanics are in GreenNode's RAM price shock analysis, and the supply outlook through 2027–2028 is covered in Avnet's memory market note. The quarterly percentages come from different trackers with different baskets — treat them as a direction, not a single series.