PostgreSQL Benchmark: AWS RDS vs. Self-Hosted on Hetzner (2026) | Hacker News Reader

PostgreSQL Benchmark: AWS RDS vs. Self-Hosted on Hetzner (2026)

hostim.dev

28 pointspv133713 comments

Red flags: - Tests Postgres 16, not 18. - Uses t4 burst instances in AWS, shared CPU in Hetzner. - Test fits in memory. - Fails to say if load generator is in same AZ. - Says their own service "includes a standby and automatic failover" but their docs do not describe this feature or its details. - Says to treat on-demand AWS EC2 price as the floor, does not consider savings plan. - Their own service describes automatic backups as a potential future feature.

There are various differences, but the price differences are incredibly stark and what the article is really about.

Most optimistic AWS bill: $48 list price (and $300 effective price, because neither storage nor network traffic is included in $48) (and, to add insult to injury, AWS is obviously not giving you the same bandwidth as an actual disk, not even half of it, about one third)

Most optimistic Hetzner bill: 19.49 euro (including storage, yes, without backup, including network traffic), 40 with redundancy.

And even though AWS comes with some redundancy by default, for actual redundancy you need a double deployment (or $600 per month)

As much as I love to discuss how expensive AWS is, I find this comparison quite strange:

- Small instances are used, including a burstable instance for AWS, with no indication on where and how much throttling happened. Saying that the instance is burstable but a price-match isn't even true because later it is discussed that $48 is not a match in price due to services around the instance itself

- It seem Hostim doesn't support large instances, the largest dedicated instance offers 100GB / 4 Cores / 8 GB RAM. At that price point, you either go with AWS for prototyping speed or compliance but definitely not for performance.

- Talking about speed, you got performance, but you'll now spend time developing your own backup and restore processes which are a "coming later" feature. What's the impact of backups compared to disk snapshots on those other network-attached disks?

- It mentions only once the network-attached block storage used by RDS and the Hetzner instance compared. Which is weird because you could go for local storage for cheaper and get more performances, but that introduces some trade-offs.

- Instances are configured with different settings.

> ...That is the realistic "install Postgres and go" baseline. RDS ran on its default parameter group, which AWS tunes for the instance size. Hostim runs its own managed tuning. In other words, the two managed options are tuned out of the box and the self-hosted default is not, and that difference is part of what you are comparing.

So... useless comparison vs Hetzner? Akin to comparing two laptops on a compile job, but leaving one in battery saver mode and then concluding that its 2x slower.

Yep quite useless. It's well known that postgres defaults are tuned for low resource usage, not for max performance. There are calculators like https://pgtune.leopard.in.ua/ to get a better than default config with next to no effort.

Why can’t Postgres auto-tune these values itself in 2026? Microsoft SQL Server has mostly done a good job of this since about 2005. It will set parallelism thresholds, soak up as much cache RAM and CPU as the runtime environment allows, etc. It will give RAM back when the OS is under memory pressure, and schedule worker threads based on current resources.

A DB with a privileged supervisor process could generally detect how much free RAM, CPU usage/layout, etc at startup and re-evaluate periodically while running.

I'd like to add: pgbench? Why not HammerDB?

its useful cause it gives a baseline

It’s like comparing the experience of buying an iPhone at an Apple Store versus ordering one online.

At the Apple Store, an employee will take off the protective film and actually help you set it up properly (RDS).

Running a benchmark on a default, unconfigured self-hosted Postgres instance is like receiving that online iPhone order, seeing it covered in shipping film, not bothering to transfer from your last phone, and trying to use it anyway.

Concluding that self-hosted is slower based on that is like complaining the iPhone screen is unresponsive while refusing to peel off the plastic just because "that's how it came out of the box." You are expected to take the film off before you use it.

It was "what do you get for least effort and what cost" kind of test

I think it actually favors Hetzner anyway. "Tuned" AWS instance is not impressive comparing it with (still, even after price hike) cheap Hetzner box.

Claude Code has been a blessing for all our devops work. We use baremetal servers and now have reliable, tested, fault tolerant postgres with streaming replication and barman for backups configured and running, with less than a second of replication lag, including a S3 redundant backup with < 1 minute of data loss (archive_timeout=60s) with S3 object-lock set up in compliance mode (so even the ransonware scenario is protected).

Yes, it takes some time to set up and test (~3 days in our case, 360GB database). But it's not that complex and the models (Opus 4.8+) know a lot about these days.

Low-effort, low-quality self-promoting slop, of the sort where you assume that significant errors are present, so obviously generated (and unedited!) is the text, but it's hardly worth your time to actually chase them down.

So a managed database provider doing comparisons of hosting databases.. what could go wrong..

Reply on news.ycombinator.com