---
title: "POSETTE Talk Recap - Postgres Isn't Slow. Your Storage Is"
description: "At POSETTE 2026, Sai Srirampur’s talk examines how storage limits can produce slow ingestion, erratic P95 reads, lagging autovacuum, slower checkpoints, and logical replication lag in large PostgreSQL workloads. The benchmark ran the same 3.3-billion-row, random-UPDATE workload on four local-NVMe clusters and four baseline gp3 EBS clusters, using m6id.4xlarge instances, 64 clients, and 16 worker threads. NVMe reached median 16,030 TPS versus 1,734 TPS on EBS, reduced median latency from 36.9 ms to 4.0 ms, and completed the tested VACUUM and replication-backlog tasks faster. The analysis attributes most of the gap to storage waits rather than CPU work, while the proposed production model combines local NVMe with quorum-based replication, external base backups, and archived WAL for recovery."
---

# POSETTE Talk Recap - Postgres Isn't Slow. Your Storage Is

[Clickhouse](https://yomu.fyi/company/clickhouse) · Aug 20, 2026

**Type:** Benchmark

## Summary

At POSETTE 2026, Sai Srirampur’s talk examines how storage limits can produce slow ingestion, erratic P95 reads, lagging autovacuum, slower checkpoints, and logical replication lag in large PostgreSQL workloads. The benchmark ran the same 3.3-billion-row, random-UPDATE workload on four local-NVMe clusters and four baseline gp3 EBS clusters, using m6id.4xlarge instances, 64 clients, and 16 worker threads. NVMe reached median 16,030 TPS versus 1,734 TPS on EBS, reduced median latency from 36.9 ms to 4.0 ms, and completed the tested VACUUM and replication-backlog tasks faster. The analysis attributes most of the gap to storage waits rather than CPU work, while the proposed production model combines local NVMe with quorum-based replication, external base backups, and archived WAL for recovery.

## Context

Large PostgreSQL workloads can develop slow ingestion, unpredictable read latency, autovacuum backlog, disruptive checkpoints, and logical replication lag as their working sets outgrow available memory and page cache. The post identifies storage performance and contention among client queries, WAL, checkpoints, VACUUM, and logical decoding as a shared possible cause.

## Approach / What changed

The benchmark compared eight otherwise identical PostgreSQL clusters: four using instance-store NVMe and four using baseline gp3 EBS provisioned at 3,000 IOPS. Each ran on an m6id.4xlarge instance with 16 vCPUs, 64 GiB of RAM, 16 GiB of shared\_buffers, and a 482 GiB, 3.3-billion-row pgbench\_accounts heap. The proposed production design adds quorum-based replication, external base backups, and continuous WAL archiving.

## Takeaways

- In the benchmark, page reads contributed about 19 ms of EBS transaction latency versus 0.3 ms on NVMe, while WAL fsync contributed 11 ms versus 1.5 ms; CPU work was about 2 ms on both.
- The NVMe host accumulated 2,253 CPU-seconds during the profiling window, compared with 251 CPU-seconds on EBS, indicating that EBS processes spent substantially more time waiting for storage.
- Local NVMe data disappears with its machine, so the production design separates performance from durability through replication, independently stored backups, and archived WAL; backups and replication serve different recovery purposes.

**Tags:** [AWS](https://yomu.fyi/topic/aws), [Performance](https://yomu.fyi/topic/performance), [Postgres](https://yomu.fyi/topic/postgres), [Reliability](https://yomu.fyi/topic/reliability)

- Source: [Clickhouse](https://clickhouse.com/blog/posette-talk-recap-postgres-isnt-slow-your-storage-is)
- Source URL: https://clickhouse.com/blog/posette-talk-recap-postgres-isnt-slow-your-storage-is
- Ingested by Yomu: 2026-08-29T07:46:40.691Z

[Read original post](https://clickhouse.com/blog/posette-talk-recap-postgres-isnt-slow-your-storage-is)