9倍性能差，元凶不是数据库

同一份负载，换个盘，TPS差了9.24倍。

POSETTE 2026大会上，ClickHouse 产品负责人 Sai Srirampur 做了一场题为《Postgres Isn't Slow. Your Storage Is.》的演讲。他只做了一件事：同一份 PostgreSQL 负载，分别跑在本地 NVMe 和 AWS EBS 上。结果本地 NVMe 拿到 16,030 TPS，EBS 只有 1,734 TPS，事务延迟差距同样悬殊。

过去十年，无数团队对着慢查询日志彻夜调优，骂索引、骂连接池、骂 Postgres 本身。这场演讲只说了一句话：先看看你的盘。

💾 一组TPS数字，撕开了行业默认设定

默认设定，往往是最贵的那个。

场景很简单：一个团队把 Postgres 搬上云，选择最主流的路径，托管数据库加块存储。这几乎是过去十年的标准答案：不用管硬件，不用管运维，按量付费。

但 Srirampur 的对比数据摆在桌上：

（事务延迟的具体数值素材中未完整公布，但方向一致：本地盘显著更低。）

这组数字的产业含义在于，它挑战的不是某个产品，而是一个默认设定：上云等于托管数据库，托管数据库等于网络块存储。这个设定让用户在过去十年里默默支付了一笔看不见的"存储税"，而账单上的每一项都合情合理。

据多位在云厂商数据库团队工作的工程师私下聊，类似结论内部并不意外，只是没人愿意在公开场合把数字摆得这么直白。

🧱 EBS到底慢在哪：三重架构税

远程块存储的每一笔写，都在付过路费。

先看清楚两条路径的差别：

本地 NVMe 是一条直线：数据库进程直接通过 PCIe 总线访问物理盘，微秒级响应。

EBS 则是一条绕路：每次 I/O 要经过虚拟化层、走网络、到达远端存储节点，再落盘。这条链路带来三重成本，虚拟化开销、网络往返延迟、以及块存储本身为通用性付出的设计折衷（要兼容各种实例、各种负载、各种容量，就不能为某一类延迟敏感场景做到极致）。

更要命的是 IOPS 上限。块存储普遍按性能档位售卖，默认档位的 IOPS 配额对高并发事务负载来说往往捉襟见肘。用户发现慢了，常规动作是升级盘、加买 IOPS——性能问题就这样变成了收入问题。

这就是"存储税"的完整逻辑：架构上绕了路，计费上还按路途收费。

⚖️ 本地盘回归：性能与可靠性的再平衡

天下没有既快又免费还持久的盘。

那为什么过去十年大家还是选了 EBS？因为本地 NVMe 有一个致命属性：它是易失的，跟实例绑定。实例释放，数据就没了。对托管数据库服务商来说，这是不可接受的，数据库的第一天职是数据不丢。

所以存储演进的时间线大致是这样的：

注意最近一段：本地盘正在回归，但不是裸回归，而是带着兜底方案回来的。典型组合是：本地 NVMe 承担主读写，靠跨机副本和异步备份保持久性，冷数据下沉到对象存储。延迟敏感的热数据走 PCIe，持久性靠拓扑设计解决。

这本质上是一次再平衡：用架构复杂度（副本管理、故障切换、数据重建）换性能。对于事务延迟直接决定业务体验的负载，这笔交换越来越划算。Srirampur 的那组数字，就是这次再平衡最有力的论据。

🏗️ 存算分离还是存算一体？没有标准答案，只有负载答案

架构选型正在从信仰问题变回工程问题。

有意思的是，行业在存储路线上分成了两个阵营，且都说自己代表未来：

Aurora、Neon 这一路押注存算分离：存储层做成独立服务，计算无状态，弹性好、故障恢复快，代价是每一次 I/O 都过网络。

ClickHouse、TiDB 等更看重单机性能的引擎则倾向本地盘：分析型负载要扫海量数据，网络延迟累积起来不可接受。

判断其实很朴素：没有哪种架构赢，只有哪种负载匹配。弹性优先、写入不密集的场景，存算分离是合理选择；延迟敏感、吞吐密集的事务和分析负载，本地盘架构的优势是碾压级的。9.24 倍这个数字，就是负载与架构错配时的代价。

💰 真正被动摇的，是云数据库的定价逻辑

当用户开始算 TCO，故事就不一样了。

必须诚实指出：这场演讲有立场。ClickHouse 自己就是本地 NVMe 架构的直接受益者，说存储慢，等于说自家快。这是产品营销，但不因为是营销就不成立，数字摆在那里，任何人都可复现。

真正的变化在需求侧。云数据库的商业模式建立在一条隐含链路上：性能不够 → 升级实例/升级盘/加买 IOPS → 账单增长。用户此前很少追问：性能瓶颈到底是引擎，还是存储？

而现在，越来越多人开始追问，并且开始算另一笔账：同样一份负载，是继续在 EBS 上加配置，还是迁到本地盘实例上，用省下的存储溢价支付副本管理的复杂度？据几位做数据库选型咨询的人说，2025 年以来这类"存储路径审计"的需求明显变多了。

这预示着云数据库竞争维度的一次下沉：从拼引擎功能，拼到拼 I/O 路径的物理诚实度。谁能在托管体验和本地盘性能之间给出更优的中间解，谁就拿下下一个十年的默认设定。

🔚 小结：换数据库之前，先换思路

Postgres 不慢，16,030 TPS 就是证明。慢的是那条从数据库进程绕经虚拟化和网络的 I/O 长征路。

这场演讲的最大价值，不是给 EBS 判了死刑，而是把一个被默认设定掩盖了十年的问题重新变成显性选择题：存算分离还是存算一体、网络盘还是本地盘、为弹性付费还是为性能付费。可以预见，"本地盘 + 副本 + 对象存储分层"的混合架构会成为高性能云数据库的主流解，而存储 I/O 路径会第一次成为选型时的显式评估项。下次数据库变慢，先别骂 Postgres，先问一句：我的盘，到底在哪？