Postgres isn’t slow, your storage is

A lot of Postgres “scaling problems” look the same: low CPU, high latency, falling insert rates, and unpredictable behavior once the dataset gets big, in the TBs. In most cases we’ve investigated, the bottleneck wasn’t Postgres it was slow or inconsistent storage.

In this talk we run the same workloads on networked block storage and on local NVMe and show what actually changes. Using perf, flamegraphs, and Postgres internal stats, we demonstrate how WAL fsync, buffer reads, and checkpoints dominate on slow IO, and how those costs largely disappear on NVMe. Insert-heavy time-series workloads scale linearly, OLTP latency stays stable under reporting queries, and performance becomes predictable.

We also show where NVMe does not help. For wide scans and repeated aggregations over hundreds of millions of rows, Postgres still spends most of its time in executor and tuple-processing code. Fast storage moves the bottleneck to CPU, but it doesn’t turn a row store into a column store.