At POSETTE 2026, Sai Srirampur presented findings on how storage performance affects PostgreSQL at scale, identifying five common symptoms teams encounter as workloads grow: slow ingestion from heavy UPDATE and UPSERT operations, inconsistent read latency with P95 queries slowing from milliseconds to seconds, autovacuum falling behind as table bloat accumulates, longer checkpoints competing with client workloads, and logical replication lag during streaming to systems like Kafka or ClickHouse.
The underlying cause often traces to storage limitations. As working sets outgrow available memory and the operating-system page cache, physical I/O increases. Client queries and background maintenance—including heap and index writes, WAL synchronization, checkpoints, VACUUM, and logical decoding—all compete for the same storage bandwidth and IOPS. When storage reaches capacity limits, operations begin blocking one another, creating the cascade of problems that appear unrelated.
To quantify the impact, Srirampur benchmarked a 3.3-billion-row PostgreSQL workload using eight identical clusters: four on instance-store NVMe and four on baseline gp3 EBS provisioned at 3,000 IOPS. All ran on m6id.4xlarge instances with 16 vCPUs and 64 GiB RAM. The workload executed random UPDATEs with 64 clients over five minutes.
Results showed NVMe clusters achieved a median 16,030 transactions per second compared with 1,734 TPS on EBS—a 9.24x difference. Median transaction latency dropped from 36.9 ms to 4.0 ms. VACUUM operations over 10 GB of bloat completed in 366 seconds on NVMe versus 964 seconds on EBS; logical-replication backlog drained in 139 seconds instead of 238 seconds.
Analyzing latency breakdowns revealed the disparity. Page reads consumed roughly 19 ms on EBS but only 0.3 ms on NVMe. WAL fsync at commit added 11 ms on EBS versus 1.5 ms on NVMe. A mid-run snapshot showed 45% of EBS backends waiting on IO:DataFileRead compared with 14% on NVMe. CPU profiling showed NVMe hosts accumulated significantly more CPU-seconds—roughly 9.4 cores busy versus one core—indicating EBS processes spent more time blocked waiting for storage rather than performing useful work.
The trade-off is that instance-store NVMe ties to machine lifetime; node loss means losing local data. The proposed production pattern addresses this through quorum-based synchronous replication with two standby candidates, maintaining backups outside individual machines, and capacity planning around available NVMe per instance type. This architecture provides durability at the cluster level rather than individual nodes.
Key facts
- Local NVMe delivered 9.24x higher transaction throughput (16,030 vs 1,734 TPS) than EBS in the benchmark
- Median transaction latency decreased from 36.9 ms on EBS to 4.0 ms on NVMe
- Page read latency dropped from ~19 ms on EBS to ~0.3 ms on NVMe
- 45% of EBS backends were waiting on storage I/O at a sample point, vs 14% on NVMe
- VACUUM on 10 GB bloat completed in 366 seconds on NVMe vs 964 seconds on EBS