Hetzner vs the RAM price spike: what SaaS infra costs in 2026
The AI boom tripled the price of the most boring line item in infrastructure. A single 32GB DDR4 desktop module that cost around £60 in 2024 now lists close to £200. Datacentre DRAM went the same way for the same reason: the AI buildout is eating the world’s memory supply. Every hosting provider has repriced accordingly, Hetzner included.
I run AlertKick, a two-region monitoring and security platform, on Hetzner, and the squeeze has reshaped more engineering decisions than invoices. Those decisions are what follows.
The fleet, honestly
Each region is a handful of node types: frontend nodes, backend/API nodes, a three-node database tier that also carries the Kafka brokers, and a utility node for observability. Nothing is large. The entire two-region fleet costs less per month than a single mid-sized instance does at a hyperscaler, which is the whole reason a bootstrapped product can afford two regions at all.
The flip side: when RAM triples in price, the cheap tiers are where it bites first. Small instances got smaller in real terms - the same money that once bought comfortable headroom now buys nodes where the OS, your services, and your monitoring stack are all elbowing each other.
Where memory pressure bit
The database tier taught me the expensive lessons. Those nodes run mongod and a Kafka broker side by side - a deliberate co-location to get an HA Kafka cluster without new servers. At generous sizes that trade is free. On lean nodes it nearly ate the region.
Three specifics worth stealing:
Default heap sizes assume rich hosts. Kafka’s JVM shipped assuming gigabytes to spare; mongod’s cache sizing likewise helps itself to a large fraction of total RAM. On a lean box those two defaults alone are oversubscription. Capping the Kafka heap to a size derived from actual throughput - a fraction of the default - freed hundreds of megabytes per node and ended a recurring cycle of kernel OOM kills. Nothing degraded, because the default was never sized for my workload in the first place.
No swap means no warning. The lean nodes originally ran swapless, so the path from “tight” to “the kernel shoots your database” had no intermediate stage. A modest swapfile with low swappiness is a buffer that turns a hard kill into a visible slowdown you can alert on and fix during working hours.
Measure before you resize. The reflex under memory pressure is “buy bigger boxes”, which at 2026 prices is exactly the reflex to distrust. The heap cap plus swap took the worst tier from routine OOM kills and load spikes to steady 65% utilisation, and spared tens of pounds a month in resizes that measurement made unnecessary. Some nodes genuinely do need the upgrade; the point is knowing which, and the observability stack answers that for less than any resize costs.
The comparison people ask for
Priced against the equivalent managed setup - managed database, managed Kafka, hyperscaler compute in two regions - the same workload lands at eight to fifteen times the monthly cost, before egress. The counterweight is real: self-hosting means the OOM kills are your 2am problem, and my time has a price too. But those incidents also forced the sizing discipline above, which is now permanent, compounding savings. The managed bill never teaches you anything; it just grows.
Cost discipline stopped being optional when RAM stopped being cheap, and the discipline is mostly “know what everything uses” rather than “spend less”.
Check current prices before quoting any of the numbers above - this market has moved every quarter since the boom started, and not in our favour.