Why Postgres Wants NVMe on the Hot Path, and S3 Everywhere Else
Companies Mentioned
Why It Matters
Separating hot and cold storage preserves PostgreSQL’s OLTP speed and reliability, preventing latency‑induced bottlenecks that can degrade user‑facing applications and increase operational costs.
Key Takeaways
- •NVMe reduces PostgreSQL commit latency to microseconds
- •S3 excels for WAL archiving, backups, and analytics
- •Consumer SSDs lack power‑loss protection, hurting fsync
- •Managed Postgres services separate hot and cold storage tiers
- •PostgreSQL 18 adds async I/O, boosting NVMe benefits
Pulse Analysis
PostgreSQL’s durability guarantees hinge on the write‑ahead log (WAL) being flushed to stable storage before a transaction is acknowledged. On enterprise‑class NVMe drives with power‑loss protection, the XLogFlush() call completes in tens of microseconds, keeping commit latency invisible to most applications. Consumer‑grade SSDs, however, often lack capacitive caches, forcing the kernel to wait longer to honor fsync promises. When a database is forced to use higher‑latency object storage like S3 for this hot path, the commit round‑trip stretches into milliseconds, directly inflating response times for low‑concurrency OLTP workloads.
The industry’s response has been to treat NVMe and S3 as complementary layers rather than interchangeable options. Managed PostgreSQL services—Amazon RDS, Azure Database for PostgreSQL, and various cloud‑native providers—deploy fast local or block storage for the WAL, buffer cache, and frequent page reads, while offloading WAL archiving, base backups, and long‑term replication to S3. This architectural split isolates latency‑sensitive operations from the durable, high‑throughput but slower object store, preserving transaction throughput and preventing resource contention when analytical queries run on replicated replicas.
Looking ahead, PostgreSQL 18’s asynchronous I/O support will let the engine issue parallel, low‑latency reads and writes more aggressively, amplifying the performance gap between NVMe and object storage. Organizations should therefore invest in enterprise‑grade NVMe for primary nodes and continue to leverage S3 for cold data, backups, and analytics pipelines. This hybrid approach maximizes cost efficiency while ensuring the database remains fast, reliable, and ready for the next generation of cloud‑native workloads.
Why Postgres wants NVMe on the hot path, and S3 everywhere else
Comments
Want to join the conversation?
Loading comments...