在 POSETTE 2026 上，Sai Srirampur 发表了演讲 "Postgres 并不慢。你的存储才慢。" 该演讲探讨了存储如何影响大规模 PostgreSQL 的性能。本文回顾了基准测试、结果揭示的内容以及针对在生产环境中运行 PostgreSQL 的本地 NVMe 所提出的架构。您可以观看下面链接中的完整演讲。演讲开始时提到了一些可能被大规模运行 Postgres 的团队所识别的症状：数据摄入速度减慢，P95 读取延迟变得无法预测，自动清理落后，检查点与实际工作负载竞争资源，或者逻辑复制积累滞后。这些问题并不总是有相同的原因，但它们可能有一个容易被忽视的共同原因：存储性能。为了理解原因，Sai 进行了一个基准测试，比较了在基线 gp3 EBS 和本地 NVMe 上相同的 33 亿行 PostgreSQL 工作负载。我们将详细说明设置和 Sai 在分析结果时发现的内容，然后总结在本地 NVMe 上运行 Postgres 的生产模式。有五个常见的问题往往会出现在 PostgreSQL 工作负载达到数百 GB 或 TB 并且以真实并发和吞吐量运行时。首先是缓慢的数据摄入。一些以 UPDATE 和 UPSERT 为重的输入管道，曾经几秒钟完成的任务，如今随着底层数据量的增长，可能需要几分钟。接下来是读取延迟的不一致。在绝大多数查询保持快速的工作负载中，偶尔有少数查询变得异常缓慢，导致 P95 延迟从毫秒级上升到秒级，仪表盘超时，且不均匀的减速使得根本原因更加难以定位。第三个问题是自动清理落后，随着 UPDATE 和 UPSERT 吞吐量的增加，因表膨胀而累积的 Gigabytes 达到 Terabytes。检查点也可能需要更长时间，并与客户端工作负载竞争 I/O 和 CPU，使得原本不明显的操作变成反复出现的延迟尖峰。最后，当 PostgreSQL 数据流向 Kafka 或 ClickHouse 等系统时，逻辑复制滞后出现。当工作集超出 PostgreSQL 可用内存和操作系统页面缓存时，更多的数据读取需要物理 I/O。在较慢的存储上，这些读取的高成本和排队会增加平均延迟和尾部延迟。客户端查询和后台维护也使用相同的存储预算。堆和索引写入、WAL 同步、检查点、VACUUM 和逻辑解码溢出竞争带宽、IOPS 和队列容量。一旦存储达到这些限制之一，操作将开始互相延迟。这就是慢存储如何成为多个看似无关 PostgreSQL 问题的根本原因的方式。本地 NVMe 的优势在于它并不是消除了 I/O，而是大幅降低了其成本。比较显示，在网络连接存储上的毫秒级操作与本地 NVMe 上可以在数十微秒内完成的操作对比。缓存未命中、WAL 刷新和维护 I/O 仍然会发生，但它们对整体系统的影响不那么显著。为了更好地理解其原因，Sai 设置了一个简单的实验，比较在 EBS 和本地 NVMe 上运行的 PostgreSQL 相似工作负载。为了将存储作为变量进行隔离，基准测试使用了八个相同的 PostgreSQL 集群：四个使用实例存储 NVMe，四个使用基线 gp3 EBS（预配 3000 IOPS）。每个集群都在 m6id.4xlarge 实例上运行，配备 16 个 vCPU、64 GiB RAM 和 16 GiB 共享缓存。我们对每种存储类型使用多个实例以规范化基准运行中的变异性。该设置使用一个包含 33 亿行的 482 GiB pgbench_accounts 堆。然后每个集群以 64 个客户端和 16 个工作线程运行相同的高度并发随机 UPDATE 工作负载五分钟：\set aid random(1, 3300000000) UPDATE pgbench_accounts SET abalance = abalance + 1 WHERE aid = :aid；简而言之，这两个组之间的唯一区别是存储类别。在这次基准测试中，NVMe 集群的中位值为 16030 TPS，而 EBS 为 1734 TPS——在此测试中差异为 9.24×。中位交易延迟从 36.9 毫秒降至 4.0 毫秒。在不同操作中，NVMe 在 366 秒内完成超过 10 GB 的清理，而 EBS 则需要 964 秒，而在 139 秒内清除了 10 GB 的逻辑复制积压，EBS 则需要 238 秒。有一个例外值得注意：这些结果适用于这个工作负载和这些存储配置。EBS 方面使用基线 gp3（预配 3000 IOPS），不同的 EBS 设置可能会产生不同的结果。通过观察 37 ms 的 EBS 事务延迟去向，使吞吐量差距更容易理解。在此基准测试中，页面读取在 EBS 上占用了约 19 毫秒，而在 NVMe 上仅占 0.3 毫秒。WAL fsync 在提交时增加了另一个