Postgres Speed: It's Your Storage, Not the DB

Unlocking Postgres Performance

The article effectively highlights a critical, often overlooked, bottleneck in PostgreSQL performance: storage I/O. By presenting a clear benchmark comparing baseline gp3 EBS with local NVMe, the author convincingly demonstrates the dramatic performance gains achievable with faster local storage, particularly for I/O-bound workloads involving updates, UPSERTs, and background maintenance tasks like VACUUM and checkpoints. The breakdown of latency contributors (page reads, WAL fsync) is particularly insightful, illustrating that the bulk of the performance gap stems from storage wait times rather than excessive CPU processing within PostgreSQL itself. The subsequent discussion on production patterns, emphasizing cluster-level durability through synchronous replication and independent backups, provides a practical roadmap for adopting this high-performance storage strategy, acknowledging the trade-off of instance-store NVMe's ephemeral nature.

However, while the article argues compellingly for local NVMe, it's crucial to acknowledge that the benchmark's specific EBS configuration (baseline gp3 at 3,000 IOPS) might not represent the full spectrum of AWS EBS capabilities. More premium EBS types like io2 Block Express could offer significantly better performance, potentially narrowing the gap, albeit at a higher cost. Furthermore, the operational complexity of managing ephemeral storage, even with robust replication and backup strategies, requires a higher level of DevOps expertise. The article correctly identifies this, but organizations without mature SRE practices might find the transition challenging. The reliance on third-party tools like WAL-G for backups, while common and effective, also introduces external dependencies. Despite these considerations, the core message remains powerful: understanding and optimizing the storage layer is paramount for scaling PostgreSQL, and local NVMe presents a compelling, albeit operationally distinct, solution for achieving peak performance.

Key Points

• PostgreSQL performance scaling issues like slow ingestion, unpredictable read latency, and replication lag are often caused by storage performance bottlenecks, not the database itself.
• A benchmark comparing baseline gp3 EBS and local NVMe showed a 9.24x throughput increase and a 10x reduction in median transaction latency with local NVMe for an update-heavy workload.
• The performance gap is primarily due to slower physical I/O on EBS (page reads, WAL fsync) causing PostgreSQL to spend more time waiting, leading to higher CPU utilization in a stalled state.
• Running PostgreSQL on local NVMe requires a production architecture that addresses the ephemeral nature of instance store by implementing cluster-level durability through quorum-based synchronous replication (ANY 1) and continuous backups to object storage (e.g., using WAL-G).
• This pattern is exemplified by real-world use cases from companies like Instacart and Datadog, demonstrating the viability of local NVMe for latency-sensitive PostgreSQL workloads.

---

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