In 2024, Gunnar Morling ran a challenge: aggregate one billion temperature readings from a text file, as fast as you can. The winning solution took 1.5 seconds. Not on a cluster. On 8 cores of a single rented server.
One billion rows. 1.5 seconds. One machine.
I keep meeting engineers who can sketch Google’s architecture from memory but can’t tell me what one modern server does. We memorized their numbers and never measured our own. So: do you know what one server can do?
Here’s the box. A Hetzner AX42 costs about €50 a month. Eight cores, 64 GB of ECC RAM, NVMe storage. The challenge machine was bigger, but results were capped to eight of its cores, five years older than these. The whole machine costs less per month than one hour of the engineer architecting around it.
64 GB of RAM means the entire customer database of almost every B2B company on earth fits in memory, with room left for ten copies.
Same story on disk. A million-row table, the kind that gets called big in planning meetings, is about 100 MB with its indexes. Twenty-five phone photos. The billion-row file from Morling’s challenge was around 13 GB. The box holds forty of them on half a terabyte of NVMe. You are not running out of disk. You have never been close.
NVMe does random reads on the order of a million IOPS. The spinning disk that your architecture patterns were designed around did about two hundred. Two hundred. Every storage pattern you learned was a workaround for that number.
Throughput is arithmetic. A sustained 1,000 requests per second is 86 million requests a day. A plain Go service does tens of thousands of requests per second on eight cores; Rails, nobody’s idea of fast, does thousands. SQLite takes tens of thousands of inserts per second batched in WAL mode, on the database engine everyone tells you is a toy.
You will probably never see 86 million requests in a day. Stack Overflow served one of the busiest sites on the internet from about nine web servers. That was a decade ago, on weaker hardware than the €50 box.
Now put a normal business next to those numbers. A B2B product with a thousand daily active users peaks at a few dozen requests per second. Its database, after years of trading, holds a few gigabytes. Its background work is thousands of jobs a day, not millions. A normal business fits in a corner of this machine, and the machine is bored.
So why do we shard databases that fit in RAM and run queue clusters for jobs one core could clear before lunch?
Because we’re running someone else’s playbook. The books and talks that taught us architecture were written by Googlers and Amazoners, solving Google and Amazon problems. Sharding made sense: their data didn’t fit on one machine. Yours does. The advice isn’t wrong. It’s wrong at your scale.
That’s the whole ask: measure. Your numbers, not theirs. Don’t engineer at their scale. Engineer at yours.