TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
At POSETTE 2026, Sai Srirampur presented a PostgreSQL benchmark comparing local NVMe with baseline gp3 EBS. In the tested 3.3-billion-row random-update workload, the NVMe clusters delivered median throughput of 16,030 transactions per second, versus 1,734 on EBS; the result applies to those specific hardware and storage settings, not PostgreSQL workloads generally.
At POSETTE 2026, Sai Srirampur presented a benchmark in which PostgreSQL running on local NVMe achieved a median 16,030 transactions per second, compared with 1,734 on baseline gp3 EBS. The test used a 3.3-billion-row database and a concurrent random-update workload, and the result points to storage as a potential bottleneck in some large PostgreSQL deployments—not proof that NVMe will deliver the same gain for other workloads.
The benchmark compared eight PostgreSQL clusters: four on instance-store NVMe and four on baseline gp3 EBS provisioned at 3,000 IOPS. Each ran on an m6id.4xlarge instance with 16 vCPUs, 64 GiB of RAM and 16 GiB of shared_buffers. The database included a 482-GiB pgbench_accounts table holding 3.3 billion rows. Each cluster ran the same five-minute test, with 64 clients and 16 worker threads issuing random UPDATEs.
Across the runs, the reported median throughput was 9.24 times higher on NVMe. Median transaction latency was 4.0 milliseconds on NVMe, against 36.9 milliseconds on EBS. Other tests reported a 10-GB-bloat VACUUM completing in 366 seconds on NVMe and 964 seconds on EBS; draining a 10-GB logical-replication backlog took 139 seconds and 238 seconds, respectively.
The report’s breakdown attributed most of the transaction-latency gap to storage waits. It put page-read time at about 19 milliseconds on EBS and 0.3 milliseconds on NVMe, and WAL fsync time at 11 milliseconds and 1.5 milliseconds. Estimated CPU work was roughly two milliseconds on each. A snapshot during the run found 29 of 64 EBS backends waiting on IO:DataFileRead, compared with nine of 64 on NVMe; the authors describe this as a point-in-time observation, not an average.
Storage Waits Shape Database Latency
The findings offer database operators a reason to investigate storage when symptoms such as slow ingestion, uneven read latency, delayed VACUUM, long checkpoints or replication lag appear together. Those problems have multiple possible causes, but they can compete for the same I/O capacity: client reads and writes, WAL synchronization, maintenance work and logical decoding all rely on storage.
For the workload tested, faster local storage coincided with much lower transaction latency and higher throughput. That matters where a database’s working set exceeds available memory and operations must wait for physical reads or writes. The results do not establish that storage is responsible for any particular production incident, or that replacing EBS with NVMe will improve every workload by the same amount. The tested EBS configuration was specifically baseline gp3 at 3,000 IOPS.
The talk also frames local NVMe as a performance choice with operational implications, rather than a drop-in change with no trade-offs. Its recap proposes production patterns for running PostgreSQL on local NVMe, but the available benchmark details do not quantify reliability, recovery, cost or operational differences between those approaches.
NVMe SSD for high performance PostgreSQL
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
How the Benchmark Isolated Storage
Srirampur’s talk, titled “Postgres Isn’t Slow. Your Storage Is,” examined storage’s role in PostgreSQL performance at scale. The accompanying ClickHouse recap describes familiar operational symptoms, including updates and upserts taking longer as datasets grow, autovacuum falling behind, checkpoints competing with application work and logical replication accumulating lag. The report presents storage as one possible shared constraint, not the sole explanation for each symptom.
To compare storage classes, the test used multiple clusters per group and kept the instance type, database workload and memory settings alike. The main variable was instance-store NVMe versus baseline gp3 EBS. The workload repeatedly selected a random account from the 3.3-billion-row table and incremented its balance, producing concurrent updates across a dataset much larger than the configured shared_buffers.
In the report’s explanation, when frequently accessed data does not fit in PostgreSQL memory or the operating-system page cache, more requests require physical I/O. Storage latency and queueing can then affect both foreground queries and background work. The benchmark measured one configuration of that situation; it is not a broad comparison of every EBS tier, NVMe device or PostgreSQL workload.
“Postgres Isn’t Slow. Your Storage Is.”
— Sai Srirampur, in the POSETTE 2026 talk title
As an affiliate, we earn on qualifying purchases.
Limits of the EBS Comparison
The reported performance gap is specific to the tested workload and storage setup. The EBS clusters used baseline gp3 provisioned at 3,000 IOPS; the recap acknowledges that a different EBS configuration would likely produce different results. It does not provide results for other PostgreSQL query mixes, database sizes, concurrency levels or provisioned storage settings.
The recap also notes that the backend-wait figures came from a single mid-run snapshot, so they cannot be treated as average wait rates over the five-minute test. The supplied source material cuts off during its discussion of CPU profiling, leaving the full profile comparison unavailable here. It also does not provide enough detail to judge cost, durability, recovery behavior or the production architecture’s failure handling. Those issues matter when comparing local instance storage with network-attached storage.
As an affiliate, we earn on qualifying purchases.
Production Trade-Offs Still Ahead
The POSETTE presentation included proposed patterns for running PostgreSQL on local NVMe in production, and ClickHouse says the full talk is available to watch. The recap does not specify a further benchmark date or announce a deployment change. Operators considering the approach would need to test their own query mix and storage configuration, then weigh measured latency and throughput against operational requirements.
Useful follow-up evidence would include results across more than one EBS performance tier, additional workloads and longer operating periods, alongside data on recovery and failure handling. Until then, the benchmark supports a narrower takeaway: storage was a major source of waiting in this test, and its reported advantage should not be assumed to transfer unchanged to other systems.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did the PostgreSQL benchmark compare?
It compared four clusters using instance-store NVMe with four using baseline gp3 EBS provisioned at 3,000 IOPS. The clusters ran the same PostgreSQL configuration and random-update workload.
How large was the reported throughput difference?
Median throughput was 16,030 transactions per second on NVMe and 1,734 on EBS, a 9.24× difference in this specific test. It is not a general performance guarantee for PostgreSQL.
Did NVMe reduce transaction latency in the test?
Yes. The recap reports median transaction latency of 4.0 milliseconds on NVMe, compared with 36.9 milliseconds on the tested EBS configuration.
Does the result show that PostgreSQL is never the bottleneck?
No. The benchmark suggests storage waits accounted for much of the latency in this workload. It does not rule out CPU, query design, locks, memory or other bottlenecks in different environments.
Can the results be applied to every EBS or NVMe setup?
No. The comparison used baseline 3,000-IOPS gp3 EBS and a particular instance type, database size and update workload. Other storage configurations and applications may produce different results.
Source: hn
Columbus Day / Indigenous Peoples' Day Picks
long weekend sales
As an affiliate, we earn on qualifying purchases.
