PostgresBench: A Reproducible Benchmark for Postgres Services

The strongest reaction was that the benchmark is useful, but the current design flatters the wrong things. The runs are only 10 minutes long, which likely misses checkpoint-driven slowdowns and hides throughput swings that matter for latency promises. Reporting average TPS without showing TPS over time was called out as especially weak because stable averages can conceal ugly operational behavior. Several people also pushed on realism. Testing without high availability strips out a very real production tax, and using local NVMe with backup and WAL archival is not the same thing as systems that synchronously replicate across nodes or maintain multiple copies by design. Default configuration was another fault line. The benchmark intentionally measures the vendor defaults, but that also means it is partly grading how conservative each managed service is out of the box rather than what Postgres on that platform can actually do. The author largely agreed and said longer durations, larger datasets, pricing, more deployment types, and HA scenarios are planned. That left the practical takeaway pretty clear. The project fills a real gap because there is very little public, repeatable data across managed Postgres offerings. But in its current state, it is a baseline harness, not a definitive leaderboard. People wanted vanilla Postgres on a VPS, bare metal, and self-managed cloud setups included for exactly that reason. The most useful way to read it is as an invitation to run the same workload in your own environment and then add the production constraints the published numbers currently leave out.