The 'RAM Is Cheap' Era Just Ended

DRAM climbed 500% in a year — 128GB of DDR5 now runs $3,399. Time to learn what your services actually need.

Dafallah Ibrahim

— 2 min read
Share

128GB of DDR5 now costs $3,399. Memory prices climbed 500% in twelve months — up to 10x the lowest prices ever tracked. The "RAM is cheap" assumption behind a decade of architecture decisions just died.

We built like memory was free: fat JVM heaps, Redis as the default answer, everything cached in-process, 64GB laptops for the whole team. Nobody measured footprint because gigabytes cost nothing. Measuring is back on the job description.

Why this matters

Hardware prices reach you through three doors. Your next dev machine or CI box. Your cloud bill, since memory-heavy instance types are priced per gigabyte and providers won't absorb a 10x DRAM swing forever. And any workload whose ceiling is capacity — local LLM inference being the loudest example.

A gigabyte you never allocate is now the cheapest optimization in your system. Most services sit on plenty: memory limits set 2-3x above reality because nobody ever measured the working set. That slack was harmless at old prices. It's rent now.

How it works

The number you want is peak working set under production load. The number most engineers have is whatever top showed them once, which is neither.

RSS lies. It counts shared libraries per process and mixes in pages the kernel can reclaim instantly. The honest accountant is cgroup v2: memory.current shows what's charged right now, and memory.peak holds the high-water mark since the cgroup was created. Inside a container, that's /sys/fs/cgroup/memory.peak — the peak for that container alone.

Better than estimating: enforce. Put the process under a hard cap and let the OOM killer tell you the truth. Binary-search the limit. One more trap: glibc malloc fragmentation can double RSS in long-running services; swapping in jemalloc is a one-line change that sometimes halves footprint.

Where this helps

  • Container right-sizing. Set limits to measured peak plus headroom, not vibes. Across a fleet, that's real gigabytes you stop renting.
  • Redis and memcached nodes. Per-GB economics got worse. Check hit rates — keys below 1% are paying rent for nothing.
  • CI pipelines. Jobs that slurp entire artifacts into memory force you onto bigger runners. Streaming fixes that permanently.
  • Local inference rigs. Build math where capacity is the bottleneck just got repriced. Re-run the spreadsheet before buying.

Watch out

memory.peak includes page cache. A service reading big files shows inflated peaks — read the anon vs file lines in memory.stat before declaring a leak.

You need cgroup v2 and kernel 5.19+ for memory.peak. Fresh distros are fine; older enterprise images may not be. RSS-based dashboards will disagree with cgroup numbers — pick one source of truth.

And don't panic: contracted cloud prices lag hardware by quarters. This is a budgeting shift, not today's incident.

Try it yourself

# Cap any process at 512MB — no Docker, no config files
systemd-run --user --scope -p MemoryMax=512M -p MemorySwapMax=0 \
  python3 -c "x = bytearray(2**30); print('survived')"
# Expect: the OOM killer answers before python does

# Measure peak RSS of any command, no profiler required
/usr/bin/time -v python3 -c "x = bytearray(2**28)" 2>&1 | grep Maximum

TL;DR

  • What changed: DRAM climbed 500% in 12 months; 128GB of DDR5 now costs $3,399.
  • Why it matters: every unmeasured, over-provisioned gigabyte across your fleet just became a line item.
  • Try today: run a service under a hard MemoryMax cap and read its memory.peak — then cut the limit to match reality.

Read more