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

Summary

At POSETTE 2026, Sai Srirampur’s talk examines how storage limits can produce slow ingestion, erratic P95 reads, lagging autovacuum, slower checkpoints, and logical replication lag in large PostgreSQL workloads. The benchmark ran the same 3.3-billion-row, random-UPDATE workload on four local-NVMe clusters and four baseline gp3 EBS clusters, using m6id.4xlarge instances, 64 clients, and 16 worker threads. NVMe reached median 16,030 TPS versus 1,734 TPS on EBS, reduced median latency from 36.9 ms to 4.0 ms, and completed the tested VACUUM and replication-backlog tasks faster. The analysis attributes most of the gap to storage waits rather than CPU work, while the proposed production model combines local NVMe with quorum-based replication, external base backups, and archived WAL for recovery.

Takeaways

1. 1

   In the benchmark, page reads contributed about 19 ms of EBS transaction latency versus 0.3 ms on NVMe, while WAL fsync contributed 11 ms versus 1.5 ms; CPU work was about 2 ms on both.

2. 2

   The NVMe host accumulated 2,253 CPU-seconds during the profiling window, compared with 251 CPU-seconds on EBS, indicating that EBS processes spent substantially more time waiting for storage.

3. 3

   Local NVMe data disappears with its machine, so the production design separates performance from durability through replication, independently stored backups, and archived WAL; backups and replication serve different recovery purposes.