Engineering

The benchmark we expected to lose

Let's start with the part that surprises people: we really like Hetzner.

If you want cheap raw performance, Hetzner is the best place on the internet to buy it. We mean that without irony. And their premium dedicated line, the CCX series, is the good stuff: in our experience it is not oversold, the numbers hold, and what you get behaves like you racked a server yourself and carved a VM out of it. Solid, boring hardware, and boring is a compliment in this business.

So naturally, we decided to run a benchmark against them.

A fight we expected to lose

Here is why this was a bad idea on paper. We took vanilla PostgreSQL, the same version, the same config formula, and put it on two comparable machines: their premium CCX box with its local NVMe, and our VM on an SDS volume: a network disk, replicated across storage nodes. Then we hammered both with the same write-heavy workload, over a ladder of database sizes, from tiny to ten times bigger than RAM. Every number, table and command from this post lives in the full technical write-up; this is the story of how it went.

The thing is, their disk is local. It sits centimeters from the CPU, and it is genuinely fast: we had already measured it in our storage benchmark, where it was one of the fastest local setups we could rent. Our disk is the opposite of that. It is a network volume, and every single write is replicated to independent storage nodes before PostgreSQL is told "done". We pay for a copy existing somewhere else, on every write, every time.

A local NVMe against a replicated network disk, on a database workload, on the defending champion's home turf. Everyone knows how that ends. We were not sure we wanted to publish this one. We did not know the result in advance, seriously. We ran it anyway.

Why pick a fight with one of the strongest players and shoot ourselves in the foot? Hell knows. Probably because if you are going to measure yourself against anyone, it should be the best one you can find.

The part we lost

Let's do the loss first, because it is real and it stays in the article.

On a small database that fits entirely in RAM, mostly serving reads, the Hetzner box won. Their machine ships with twice the memory of ours at this price point, their read path is quick, and on a hot little database that is exactly what matters. If that is your workload, buy their box; you will be happy. We wrote that in the technical article and we will say it here too.

The part we didn't

Then the database grew, the workload started writing, and the tables turned.

Writes: our box was faster at every single database size, small or huge, by double digits. The whole transaction path, network included, is shorter and steadier on our side.

And then the test we were actually afraid of: the raw commit race. One INSERT, one COMMIT, sixty-four writers, no place to hide. Every commit has to reach durable storage before the database answers. This is the exact discipline where a replicated network disk is supposed to get slaughtered by local NVMe, because our commit has to cross the network and land on multiple machines while theirs just drops into a cache one bus away.

Our disk out-committed theirs by twenty percent. While writing every byte twice, across independent machines, any one of which can die without losing the volume or forcing a restore.

The commit race: durable commits per second, 64 writers 0 20k 40k 34,800 Hetzner local NVMe 41,878 ServersCamp replicated SDS single INSERT + COMMIT per transaction, every commit waits for durable storage
The discipline network storage was supposed to lose. Each ServersCamp commit is written to independent storage nodes before PostgreSQL answers.

We stared at that number for a while.

Why that happened

No miracle, just two pieces of engineering that finally got to show off. The write cache on our storage is power-loss protected, so a commit is durable the moment it lands in it, at full speed. And the fabric that carries the write between machines is fast enough that "somewhere else" is closer than you think. We wrote up how that works in the storage docs, with the fio numbers to back it, if you like the gory details.

The point of this post is not the twenty percent. The point is that the entire reason this company exists was on the table. We built ServersCamp around one bet: that network storage can be fast enough that you stop paying the safety tax, that you can have the disk that survives a dead host and the speed of the disk that does not. That bet is our origin story. This benchmark was that bet meeting the best opponent we could find, in the discipline it was supposed to lose.

The scoreboard

These are results for the two configurations tested, at prices available on July 21, 2026. Not a universal ranking of either platform.

One thing has to be said directly, because burying it would be cheap: divide the results by the money, and we lost. Per euro, Hetzner delivers more raw performance. Plainly. That is their crown, they have worn it for years, and this test did not take it from them:

Performance per euro of the monthly billHetznerServersCamp
Read qps per euro, small in-RAM database558422
Read qps per euro, 88 GB database261245
Write tps per euro, 88 GB database54.653.3

If your only metric is transactions per euro, buy Hetzner and do not look back: they are the king of cheap raw performance, and we say that as a competitor who just spent a day trying to prove otherwise.

Our result is a different one. In absolute numbers, in the heaviest regimes a database actually fears - data far bigger than RAM, relentless writes, commit storms - our box was simply faster:

Absolute numbers, heavy regimesHetznerServersCamp
Writes, 44 GB database (tps)~5,0005,631 (+13%)
Writes, 88 GB database (tps)4,7265,504 (+16%)
Commits per second, 64 writers34,80041,878 (+20%)
Reads, 88 GB database (qps)22,54425,303 (+12%)
Reads on a written-to database, 44 GB (qps)21,88224,837 (+13.5%)

And it is faster while being a cloud disk: it survives its host dying, grows online, changes speed class under a live database, and ships encrypted backups to another country. That combination is the thing we set out to build, and in the commit race it beat local NVMe outright, in the configurations customers actually buy.

And then your database grows

One more table, because this is where local disks stop being a performance story and become a money story. The boxes we tested carry 160 GB of disk. Now imagine the day your database reaches 500 GB.

 HetznerServersCamp
The boxes from this test (~120 GB of database)CCX23, EUR 86.49/mohf-m + 160 GB W4, EUR 103.22/mo
500 GB database, staying on the comparable storage tierThe smallest CCX with enough local NVMe is the CCX53 (600 GB): EUR 533.49/mo, and it comes welded to 32 vCPU and 128 GB of RAM whether you need them or notThe same VM, the same disk resized online to 600 GB: EUR 231.70/mo, database running throughout
500 GB database, budget pathKeep the CCX23 and attach a network volume for a few dozen euros - which moves the database off the local NVMe this whole benchmark was about, onto their standard volume tierThere is no second tier to fall onto: the disk in this test is already the network disk, already replicated, already at these numbers

That is the quiet cost of a local disk: storage is welded to compute, so past a certain size you buy CPUs to get gigabytes. With the disk as its own thing, you buy exactly the gigabytes, live, and the database does not stop while you do it.

Who should go where

Go to Hetzner ifGo to ServersCamp if
You want maximum raw performance per euro and the budget decides Your database writes for a living: OLTP, queues, events, commit-heavy anything
Your database is small, hot and read-heavy, and will stay that way Your database will outgrow RAM and keep growing, and you want to scale the disk without replacing the server
You are comfortable owning durability yourself: backups, replicas, the plan for the day the host dies The data must survive the death of the physical host on its own: the disk is replicated across storage nodes, so a dead hypervisor means a VM restart, not a restore from backup

Where this leaves us

We respect Hetzner more after this test, not less. Their box did what good hardware is supposed to do: it delivered strong numbers without a hint of overselling. That is rarer than it should be, and it is why we chose them as the opponent.

And we are a little proud. Quietly. The kind of proud you allow yourself after you point a benchmark at your own head, pull the trigger, and it clicks.

All the numbers, tables, charts, the exact commands and the full list of caveats live in the technical write-up. Everything reproduces from a plain console in one afternoon, on your own accounts, on both sides. If your numbers come out different, that is a bug report, and we mean it.