> ...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.

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.

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..

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.

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.