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.
> ...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.
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.
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.
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.
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.
> ...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.
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.
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.
I'd like to add: pgbench? Why not HammerDB?
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.
its useful cause it gives a baseline
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.
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.
So a managed database provider doing comparisons of hosting databases.. what could go wrong..
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.
[dead]