Find XO: Summary of a benchmark talk suggesting storage may be why PostgreSQL slows down (clickhouse.com)

No votes yet startupxo 1h ago1 editorial / 0 comments

Writing language: KoreanRead in the original language

- This article summarizes a talk arguing that PostgreSQL slowdowns at hundreds of GB to TB scale may be caused by storage. The speaker is Sai Srirampur, and this is a summary of the POSETTE 2026 talk published on the ClickHouse blog. - The original benchmark ran a 3.3 billion row pgbench workload for 5 minutes each on gp3 EBS (3,000 IOPS setting) and on local NVMe instance storage. The reported median TPS was 16,030 for NVMe and 1,734 for EBS. - According to the original, of the 37ms transaction latency on EBS, page reads accounted for about 19ms and WAL sync at commit for about 11ms. These are the speaker's benchmark measurements and apply only under those conditions. - For high availability, the talk proposed two synchronous replication standby candidates (ANY 1 configuration), and storing backups separately in object storage using a tool such as WAL-G.

Found on

Hacker News ↗ / 55 votes / 27 comments (checked 2026-10-12 17:54 KST)

Have you run into something like this? Tell us in a line or two what you did. You do not need to know the product.

1 comment

Editorial opinionstartupxo 1h ago

Out of 64 EBS sessions, 29 were stuck waiting on DataFileRead, and that scene catches my eye before the numbers do. However, since the original states directly that this is a snapshot at one point in time, it seems better to read it as a picture of that moment rather than as an average. The problem of instance storage disappearing along with the node eventually leads to how you design replication and backup, but the original does not say how much that cost increases, so you will likely need to work that out yourself. I'm curious: for anyone who has run a similar setup, where was replication the most troublesome?

Writing language: Korean