Postgres isn’t slow, your storage is
summary
Benchmarks show Postgres on local NVMe achieves about 9x throughput and 4 ms median update latency versus 37 ms on EBS in a 3.3B-row pgbench workload; profiling with Parca, pg_stat_activity and block I/O traces attributes most of the gap to WAL fsync and page reads on network storage. VACUUM completes 366s on NVMe vs 964s on EBS, logical replication decodes ~89 Mbps vs 52 Mbps. Production design combines quorum replication with up to two standbys, continuous WAL archival to S3 via WAL‑G, and orchestration with repmgr to get NVMe latency with EBS-like durability.
AI-written summary · about
chapters (14)
- 0:00Music & introduction
- 0:10What actually breaks as your workload grows
- 0:45Why this comes from real production experience
- 1:30Five ways Postgres starts to fall behind
- 3:00How disk IO turns into latency and timeouts
- 5:05Why the gap between memory and disk matters
- 6:10How NVMe changes cache misses and commits
- 7:10What makes NVMe risky in the cloud
- 8:30How the NVMe vs EBS benchmarks were set up
- 11:35Why NVMe is faster even when CPU looks busy
- 13:51Why NVMe is dramatically faster
- 16:00Beyond updates: vacuum and replication gains
- 18:07Building a production NVMe architecture
- 23:15Key takeaways and closing thoughts
related talks
46mUnlock PostgreSQL’s True Performance with Local SSDs
50mPostgres vs. Linux filesystems
28mRun PostgreSQL in Warp Speed Using NVMe/TCP in the Cloud
42mPostgreSQL Distributed: Architectures & Best practices
17mThe Evolution of Postgres Performance
10mPostgres on AWS: Run 5X faster on metal, migrate anywhere
41mLinux IO internals for PostgreSQL administrators in 2023
36mBest Practices in PostgreSQL Tuning: Navigating Key Performance Bottlenecks in the Cloud