PostgreSQL Benchmark: AWS RDS vs. Self-Hosted on Hetzner (2026)
In this technical retrospective (2026), @pv1337 shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE 5 points
TOTAL DISCUSSIONS 0 comments
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... 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.
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.
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.