Postgres isn't slow, your storage is

A presentation at POSETTE 2026 argues that many large-scale PostgreSQL performance problems - slow ingestion, spiking P95 reads, autovacuum lag, heavy checkpoint interference, and logical-replication delay - are rooted in storage performance rather than the database itself. A controlled benchmark compared eight identical Postgres clusters (m6id.4xlarge, 16 vCPU, 64 GiB RAM, 16 GiB shared_buffers) running a 482 GiB pgbench_accounts heap with 3.3 billion rows under a highly concurrent random-UPDATE workload (64 clients, 16 worker threads, 5 minutes). The only variable was storage: instance-store NVMe vs gp3 EBS provisioned at 3,000 IOPS. NVMe achieved a median 16,030 TPS versus 1,734 TPS on EBS (9.24×), with median latency 4.0 ms vs 36.9 ms. VACUUM of 10 GB bloat ran in 366s on NVMe vs 964s on EBS; draining a 10 GB logical-replication backlog took 139s vs 238s.

Profiling shows most of the EBS penalty came from waiting on storage: page reads ~19 ms on EBS vs 0.3 ms on NVMe, WAL fsync ~11 ms vs 1.5 ms, lock/scheduler overhead ~5 ms vs 0.2 ms; CPU work was ~2 ms both cases. Pg_stat_activity snapshots showed far more EBS backends waiting on I/O, and total CPU-seconds were much higher on NVMe (2,253s vs 251s), meaning NVMe hosts kept CPUs busy doing useful work. To run NVMe-backed Postgres in production, design around node-local durability: synchronous quorum replication with two standbys (ANY 1), continuous base backups and WAL archiving to object storage (e.g., WAL‑G), cross-region copies, and regular testing of failover and restores; production users like Instacart and Datadog report similar patterns.