ClickHouse's Postgres Benchmark Puts Local NVMe 9.2x Ahead of Baseline gp3

A ClickHouse blog post says PostgreSQL on local NVMe drives sustained 16,030 transactions a second against 1,734 on EBS gp3 volumes, a 9.24x gap, on identical AWS instances. The post, a recap of a POSETTE 2026 talk by Sai Srirampur and published Aug. 20, 2026, argues that when Postgres slows down, the storage is often the cause. ClickHouse sells a managed Postgres service, so the figures are vendor-supplied and nobody independent is named as having reproduced them.

The numbers are worth reading closely anyway, because the post publishes its setup. The useful question is what the 9.24x tells a team that is not running this exact workload.

The setup behind the 9.24x

The test used eight identical PostgreSQL clusters on m6id.4xlarge instances: four on the instances' local NVMe storage and four on gp3 EBS volumes provisioned at 3,000 IOPS. AWS lists the m6id family at 16 vCPUs and 64 GiB of memory for that size, and the post sets shared_buffers to 16 GiB.

The dataset is a 482 GiB pgbench_accounts table of 3.3 billion rows. The workload is random single-row updates, run for five minutes with 64 clients. Memory holds a small fraction of that table, so nearly every update has to read a page from storage first. The test is built to be storage-bound, and the post says as much: "the only difference between the two groups was the storage class."

The photo above shows an HGST SN150 NVMe add-in card, an example of the drive class and not the hardware in the test.

What each metric shows

Metric	Local NVMe	gp3, 3,000 IOPS
Median transactions per second	16,030	1,734
Median transaction latency	4.0 ms	36.9 ms
VACUUM over 10 GB of bloat	366 s	964 s
Drain a 10 GB logical-replication backlog	139 s	238 s

The gap is widest on the update workload and narrows on maintenance work. By the post's own figures, VACUUM ran 2.6 times faster on NVMe and the replication backlog drained 1.7 times faster. A team whose pain is replication lag should expect a smaller win than a team whose pain is update throughput.

1. Local NVMe16K TPS
2. gp3, 3,000 IOPS1734 TPS

Source: ClickHouse POSETTE 2026 talk recap, Aug. 20, 2026 (vendor-supplied)

The post breaks the roughly 37 ms EBS latency into parts: page reads at about 19 ms against 0.3 ms on NVMe, the WAL fsync at commit at about 11 ms against 1.5 ms, and lock and scheduler overhead at about 5 ms against 0.2 ms. CPU work is about 2 ms on both. Its summary is that "most of the additional EBS latency came from waiting on storage, not from PostgreSQL doing more CPU work."

A consistency check on the headline, using the post's own figures: 64 clients each waiting 36.9 ms works out to about 1,734 transactions a second, and 64 clients at 4.0 ms works out to 16,000. The throughput gap and the latency gap are the same measurement seen twice, not two independent results.

The baseline the test chose

AWS's documentation says gp3 volumes deliver a baseline of 3,000 IOPS included in the storage price, and that customers can provision more, up to 80,000 IOPS, at additional cost. Baseline throughput is 125 MiB/s, with provisioning up to 2,000 MiB/s. The test used the floor of that range.

AWS also recommends io2 Block Express volumes for latency-sensitive workloads and says they are designed for an average latency under 500 microseconds on 16 KiB operations. Neither a provisioned gp3 volume nor io2 appears in the post's results. The article itself concedes the point: its results apply to this workload and these configurations, other EBS setups would likely differ, and it reports medians and single snapshots without variance.

The post also offers a snapshot of pg_stat_activity partway through the run: 29 of 64 backends on EBS were waiting on IO:DataFileRead, about 45 percent, against 9 on NVMe, about 14 percent. It labels that a point-in-time reading, not an average.

What local NVMe costs you

The post is plain about the trade. Local NVMe is tied to the machine's lifetime, instance-store volumes cannot be snapshotted through the EBS API, and available capacity depends on the instance type. Its answer is to move durability into the cluster: quorum synchronous replication with two standbys using ANY 1 (standby1, standby2), spread across availability zones, plus continuous backups to object storage with WAL-G.

It cites Instacart as running PostgreSQL on NVMe for a latency-sensitive search workload and Datadog for local-NVMe instances where workloads need them. Both are named only as examples; the post does not give their numbers.

What a reader can actually do with this

The post's own list of symptoms is the practical filter: slow ingestion on UPDATE-heavy pipelines, read latency whose P95 climbs from milliseconds to seconds, autovacuum falling behind. If those match, the first test is cheap. Check how many IOPS the volume is provisioned for and compare against what the database is asking for, before comparing storage types.

More software reporting from this week includes Cloudflare's free-tier AI agent allowance and Cloudflare's Deno runtime story. The number to watch for this story is a reproduction: the same 3.3-billion-row test on a gp3 volume provisioned at 16,000 IOPS or higher, which the post does not include.