A PostgreSQL benchmark presented at POSETTE 2026 found that local NVMe storage delivered more than nine times the transaction throughput of baseline Amazon EBS in a large random-update workload. The result, recapped by ClickHouse, highlights how storage bottlenecks can appear as slow queries, vacuum delays, checkpoint spikes and replication lag even when the database engine and available CPU are not the limiting factors.
The test used eight otherwise identical PostgreSQL clusters: four with instance-store NVMe and four with gp3 EBS provisioned at 3,000 input/output operations per second. Each ran on an `m6id.4xlarge` instance with 16 virtual CPUs, 64 GiB of memory and 16 GiB assigned to `shared_buffers`. The dataset was a 482 GiB `pgbench_accounts` table containing 3.3 billion rows. Each cluster processed the same five-minute random-update workload with 64 clients and 16 worker threads.
The NVMe systems produced a median 16,030 transactions per second, compared with 1,734 on EBS—a 9.24-fold difference in this configuration. Median transaction latency fell from 36.9 milliseconds on EBS to 4 milliseconds on NVMe. Maintenance tasks improved too: vacuuming 10 GB of bloat took 366 seconds rather than 964, while draining a 10 GB logical-replication backlog took 139 seconds instead of 238.
Timing data showed where the gap emerged. Page reads accounted for about 19 milliseconds of an EBS transaction and 0.3 milliseconds on NVMe. Synchronising the write-ahead log at commit added roughly 11 milliseconds on EBS and 1.5 milliseconds on NVMe. CPU work remained close to 2 milliseconds in both groups, indicating that additional EBS latency largely came from waiting on storage.
A point-in-time activity snapshot reinforced that explanation. Twenty-nine of 64 EBS backends were waiting on data-file reads, compared with nine NVMe backends. The faster host also accumulated much more CPU time during profiling because it could keep processors occupied with useful database work instead of leaving sessions blocked on I/O.
The comparison has clear limits. Baseline gp3 at 3,000 IOPS represents one EBS configuration, and differently provisioned network storage could narrow the result. The workload was deliberately update-heavy and larger than memory, so it should not be treated as a universal forecast for every PostgreSQL application.
Local NVMe also changes the reliability model. Instance storage is tied to a machine and disappears when that node is lost. Production use therefore requires durability at the cluster level, with replication, backups and recovery procedures designed around disposable nodes. The benchmark’s lesson is not simply to replace EBS. It is to measure storage waits before blaming PostgreSQL, then balance latency, cost and failure recovery for the application’s actual workload.
