Postgres Isn't Slow. Your Storage Is: POSETTE 2026 Talk Recap

The Benchmark Setup

At POSETTE 2026, Sai Srirampur presented "Postgres Isn't Slow. Your Storage Is," a talk examining how storage performance affects PostgreSQL at scale. The presentation identified five common scaling symptoms: slow ingestion, inconsistent read latency, autovacuum falling behind, slower checkpoints, and logical replication lag. These issues often share a root cause in storage performance once the working set outgrows available memory.

To isolate storage as the variable, the benchmark used eight identical PostgreSQL clusters: four on instance-store NVMe and four on baseline gp3 EBS provisioned at 3,000 IOPS. Each cluster ran on an m6id.4xlarge instance with 16 vCPUs, 64 GiB of RAM, and 16 GiB of shared_buffers. The workload used a 482 GiB pgbench_accounts heap containing 3.3 billion rows, running a highly concurrent random-UPDATE workload for five minutes with 64 clients and 16 worker threads.

What the Results Showed

The benchmark produced a median 16,030 TPS for the NVMe clusters compared with 1,734 TPS on EBS, a 9.24x difference. Median transaction latency fell from 36.9 ms to 4.0 ms. For maintenance operations, NVMe completed a VACUUM over 10 GB of bloat in 366 seconds versus 964 seconds on EBS, and drained a 10 GB logical-replication backlog in 139 seconds instead of 238 seconds.

The latency breakdown showed that page reads accounted for about 19 ms on EBS versus 0.3 ms on NVMe, WAL fsync added 11 ms versus 1.5 ms, and lock and scheduler overhead contributed 5 ms versus 0.2 ms. CPU work was roughly the same at about 2 ms in both cases. A pg_stat_activity snapshot showed 29 of 64 EBS backends waiting on IO:DataFileRead compared with nine on NVMe. Over a 240-second profiling window, the NVMe host accumulated 2,253 CPU-seconds while the EBS host accumulated only 251, indicating that EBS processes spent far more time off-CPU waiting for storage.

Running NVMe-Backed Postgres in Production

The production architecture presented in the talk addresses the durability limitations of instance-store NVMe through three requirements: replicate the database so the service can survive node loss, maintain backups and recovery data outside individual machines, and plan capacity around the NVMe available on each instance type.

The first pattern is quorum-based synchronous replication with two standby candidates using a configuration such as ANY 1 (standby1, standby2), allowing a transaction to commit after either standby acknowledges its WAL. For durability outside the database nodes, open-source tools such as WAL-G can provide physical base backups and continuous WAL archiving, targeting an RPO measured in seconds. The talk cites public examples from Instacart and Datadog, both of which have described running PostgreSQL on local NVMe for latency-sensitive workloads.

Sources: clickhouse.com