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

Sai Srirampur’s POSETTE 2026 talk examines how storage constraints can contribute to PostgreSQL scaling issues such as slow ingestion, inconsistent tail latency, autovacuum backlog, checkpoint contention, and logical replication lag once workloads exceed available memory and require frequent physical I/O. In a benchmark using identical PostgreSQL clusters with a 3.3-billion-row table and concurrent random updates, local instance-store NVMe achieved a median 16,030 TPS versus 1,734 TPS on baseline gp3 EBS configured for 3,000 IOPS, while median transaction latency declined from 36.9 ms to 4.0 ms; NVMe also completed vacuuming and replication-backlog recovery faster in this specific test. Profiling attributed most of the difference to lower page-read and WAL fsync wait times rather than CPU work, allowing NVMe-backed systems to keep more CPU capacity productive. Because local NVMe data is lost when a node fails, the proposed production design combines it with quorum-based synchronous replication across availability zones, independently stored base backups and continuous WAL archiving for point-in-time recovery, and capacity planning based on available instance storage.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.