Uploaded June 2026 | Updated September 2026, 2 weeks ago
Understand why large dataset bottlenecks are often due to storage rather than Postgres. Sai Srirampur (ClickHouse) explains this in his talk “Postgres isn’t slow, your storage is” at POSETTE: An Event for Postgres 2026. Abstract: 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.
Sai Srirampur is a Director at ClickHouse, where he leads all Postgres efforts. Prior to ClickHouse, he was the CEO and Co-founder of PeerDB, which was acquired by ClickHouse. Before that, he was a leader on the Microsoft Postgres team and an early engineer at Citus Data.
► Video chapters:
⏩ 00:00 – Music & introduction
⏩ 00:10 – What actually breaks as your workload grows
⏩ 00:45 – Why this comes from real production experience
⏩ 01:30 – Five ways Postgres starts to fall behind
⏩ 03:00 – How disk IO turns into latency and timeouts
⏩ 05:05 – Why the gap between memory and disk matters
⏩ 06:10 – How NVMe changes cache misses and commits
⏩ 07:10 – What makes NVMe risky in the cloud
⏩ 08:30 – How the NVMe vs EBS benchmarks were set up
⏩ 11:35 – Why NVMe is faster even when CPU looks busy
▶️ 13:51 – Why NVMe is dramatically faster
▶️ 16:00 – Beyond updates: vacuum and replication gains
▶️ 18:07 – Building a production NVMe architecture
▶️ 23:15 – Key takeaways and closing thoughts
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
Understand why large dataset bottlenecks are often due to storage rather than Postgres. Sai Srirampur (ClickHouse) explains this in his talk “Postgres isn’t slow, your storage is” at POSETTE: An Event for Postgres 2026. Abstract: 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.
Sai Srirampur is a Director at ClickHouse, where he leads all Postgres efforts. Prior to ClickHouse, he was the CEO and Co-founder of PeerDB, which was acquired by ClickHouse. Before that, he was a leader on the Microsoft Postgres team and an early engineer at Citus Data.
► Video chapters:
⏩ 00:00 – Music & introduction
⏩ 00:10 – What actually breaks as your workload grows
⏩ 00:45 – Why this comes from real production experience
⏩ 01:30 – Five ways Postgres starts to fall behind
⏩ 03:00 – How disk IO turns into latency and timeouts
⏩ 05:05 – Why the gap between memory and disk matters
⏩ 06:10 – How NVMe changes cache misses and commits
⏩ 07:10 – What makes NVMe risky in the cloud
⏩ 08:30 – How the NVMe vs EBS benchmarks were set up
⏩ 11:35 – Why NVMe is faster even when CPU looks busy
▶️ 13:51 – Why NVMe is dramatically faster
▶️ 16:00 – Beyond updates: vacuum and replication gains
▶️ 18:07 – Building a production NVMe architecture
▶️ 23:15 – Key takeaways and closing thoughts
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
