Postgres isn't slow — your storage is: local NVMe delivers 9.24× more throughput than EBS
Postgres isn't slow, your storage is
Sai Srirampur's POSETTE 2026 talk benchmarks the same 3.3-billion-row PostgreSQL workload on local NVMe and baseline gp3 EBS. NVMe hit a median 16,030 TPS versus 1,734 TPS on EBS — 9.24× faster — with median latency dropping from 36.9 ms to 4.0 ms. Most EBS latency came from waiting on storage, not CPU. The talk then outlines a production architecture for local NVMe: quorum-based synchronous replication, WAL-G backups, and capacity planning.
The case for local NVMe is not that it eliminates I/O, but that it can sharply reduce its cost.
- mmnfrdmcx
Cloud is insanely expensive and inefficient. Too many engineers don't understand how slow I/O back and forth is on network storage, or VMs with chatty neighbors are compared to bare metal...
- bob1029
SQLite + NVMe feels like cheating sometimes. If my #1 requirement is lowest possible latency, I can't imagine picking anything else.
Kestrel (AspNetCore) + SQLite + NVMe all on the same machine is where things start to get really spicy in my experience. Imagine handling an entire form submission that mutates database state in tens to low-hundreds of microseconds. Total wall clock time required to service any HTTP request can be well under a single millisecond. If your average cpu time per request is 30uS, you could approach half a million per second on a 16-32 core machine.
- CharlieDigital
"Back in the day", we used to have to carefully plan the underlying storage array to eek out every ounce of performance from the database server.
I think there's a generation of devs that just takes big memory pools and SSDs for granted; there's a mental disconnect to the fact databases map the underlying storage.
It becomes obvious once I bring it up with them in discussion and I can almost see the bulb go off (happened while discussing partitioning and sharding), but they never make the connection that a query is mapping to some artifacts sitting on storage.
- iancarroll
Recently moved our RDS instances from r8g. to r8gd., which adds local NVMe, and I think the average I/O latency went from 1.0ms to 0.1ms. Adds up in big queries!
- smartbit
CloudNativePG supports Kubernetes Local Storage as one of its main features [0]
Persistent volume management, including:
Support for Local Persistent Volumes with PVC templates.
Reuse of Persistent Volumes storage in Pods.
Separate volumes for WAL files and tablespaces.
Chapter Temporary PostgreSQL Cluster Degradation [1] describes how to set it up and starts with this
> While the standard approach ensures service reliability and leverages Kubernetes' self-healing capabilities, there are scenarios where operating with a temporarily degraded cluster may be acceptable. This is particularly relevant for PostgreSQL clusters relying on node-local storage, where the storage is local to the Kubernetes worker node running the PostgreSQL database. Node-local storage, or simply local storage, is employed to enhance performance.
[0] https://cloudnative-pg.io/docs/devel/#main-features
[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...
- dangoodmanUT
This is the fundamental issue with networked storage: all apps on top assume small io is fast an local, so network latency doesn't amortize.
With application-level replication, you can amortize it to a few steps (e.g. on commit, do 2PC).
Obviously there's nuance, esp if you have to read from another node, but it's why moving replication as far up the stack as possible generally performs better with DBs -- the DB knows when to touch the network better than the disk.
- nasretdinov
Honestly the network-attached storage only ever made sense with HDDs, it's ridiculous to have to pay 10x penalty for both iops and latency just for some "operational flexibility". You get way simpler and much more robust architecture if you just stick to local NVMe and replication -- not that you can forgo one in the (also replicated) network block storage solution anyway...
- kebsup
I was using postgres for embarrassingly long time before I've learned the difference between "index scans" and "index only scans".
Including relevant columns in the index can massively improve the performance, because postgres does not need to read the randomly sorted tuple in the original table.