ClickHouse 这次没有只说“我们的 Postgres 很快”。它直接搭了一个公开榜单：PostgresBench。
最扎眼的是 16 vCPU 档。100GB 数据规模下，ClickHouse 托管 Postgres 约 28668 TPS；500GB 下约 26328 TPS。对比对象包括 AWS Aurora、AWS RDS、Neon、Crunchy Bridge。差距不小。
但这件事的重点，不是给托管 Postgres 排座次。
它真正拷问的是另一件事：写密集 OLTP 场景里，数据库提交一次事务，到底要走多长的存储路径。WAL、fsync、I/O 延迟，这些平时躲在架构图背后的东西，被 ClickHouse 拉到了前台。
PostgresBench 到底测了什么
PostgresBench 基于 PostgreSQL 自带的 pgbench。负载是 TPC-B-like 短事务，偏写密集。
它更像是在压支付、订单、库存这类场景：高并发、小事务、频繁更新。不是复杂分析查询，也不是混合业务全景。
测试参数不复杂：256 clients、16 threads、每轮 10 分钟，三次运行取指标。数据规模两档：100GB 和 500GB。
| 项目 | 内容 |
|---|---|
| 工具 | PostgreSQL 自带 pgbench |
| 负载 | TPC-B-like，短事务，写密集 |
| 并发 | 256 clients / 16 threads |
| 时长 | 每轮 10 分钟 |
| 运行方式 | 三次运行取指标 |
| 数据规模 | 100GB、500GB |
| 对比服务 | ClickHouse 托管 Postgres、AWS Aurora、AWS RDS、Neon、Crunchy Bridge |
结果锚点也清楚。
| 数据规模 / 规格 | ClickHouse 托管 Postgres 结果 | 读法 |
|---|---|---|
| 100GB / 16 vCPU | 约 28668 TPS | 同档对比中明显领先 |
| 500GB / 16 vCPU | 约 26328 TPS | 数据变大后仍保持较高吞吐 |
这里必须划线：PostgresBench 不是独立第三方评测。它是 ClickHouse 发起的公开可复现 benchmark。
代码、配置、结果开放，这是进步。赛场由参赛者搭建，也必须记住。
对正在选型的后端负责人来说，这份榜单适合拿来做两件事：一是复现实验，二是逼供应商解释存储路径。它不适合直接变成采购单。
这个榜单真正打的是共享存储架构
ClickHouse 给出的解释很直接：它的托管 Postgres 使用与计算共置的 NVMe 本地存储，减少 fsync、WAL 和提交确认中的 I/O 延迟。
对照路径不一样。AWS RDS 常见底座是 EBS。Aurora 是共享存储架构。Neon 采用分离式存储设计。
这不能简单翻译成“谁的产品差”。它们追求的目标不同。
共享存储、网络存储、分离式架构，通常换来弹性、恢复、扩展和托管便利。代价也很现实：写入路径更长，提交确认可能多走一段网络。
| 路线 | 可能收益 | 写密集场景的现实代价 |
|---|---|---|
| 本地 NVMe 与计算共置 | 延迟低，写入路径短 | HA、迁移、恢复、弹性设计压力更大 |
| EBS / 网络存储 | 云上成熟，运维模型清晰 | I/O 路径更长，延迟更容易暴露 |
| 共享存储 | 故障切换、扩展、管理能力强 | 写提交要经过共享存储层 |
| 分离式存储 | 弹性、冷热分层、架构灵活 | 事务写入对网络和存储服务更敏感 |
Postgres 的很多性能争论，最后都会落到老话：“兵马未动，粮草先行。”今天的粮草，就是 WAL、IOPS、延迟和确认路径。
我更在意的是，ClickHouse 把托管数据库的一个真实成本摆出来了。
云数据库卖的是省心。省心当然有价值。但它不是免费的。成本可能体现在价格上，也可能体现在 P99 延迟、默认配置、HA 取舍和架构边界里。
如果你的团队跑的是写多、低延迟、P99 很敏感的业务，这个 benchmark 至少应该改变一个动作：别只问“支持哪些功能”，要追问“写入到底落在哪里”。
更具体一点，采购和架构评审可以延后拍板，先补三组测试：自己的 schema、自己的事务比例、自己的高峰并发。厂商榜单只能开题，不能替你交卷。
公开 benchmark 是好事，但限制要一起读
这次测试的限制不小。
它没有比较价格。HA 关闭。使用默认配置。Aurora 的内存规格也不同：16 vCPU 档是 128GB，而多数对照是 64GB。
这些变量足以影响采购判断。
| 限制 | 为什么重要 |
|---|---|
| 未比较价格 | TPS 高不等于性价比高 |
| HA 关闭 | 不能代表生产环境完整形态 |
| 默认配置 | 各家默认值可能偏向不同目标 |
| Aurora 内存规格不同 | 横向对比不完全等价 |
| 只测 pgbench 写密集负载 | 不代表复杂查询、混合负载和长期稳定性 |
| 由 ClickHouse 发起 | 公开可复现，但天然带立场 |
所以，能得出的结论要收窄。
目前材料支持的判断是：在这组配置、这类 pgbench 写密集短事务下，计算共置的 NVMe 本地存储路线展示出很强优势。
它不能证明 ClickHouse 托管 Postgres 综合能力最强。价格、HA、备份恢复、跨区容灾、生态兼容、运维成熟度，都不在这次分数里。
但这个收窄后的结论，已经够有分量。
过去几年，数据库市场很爱讲 serverless、存算分离、弹性扩缩、全球复制。这些方向不是错。只是 OLTP 写入压力一上来，物理世界会重新收费。
网络有距离。存储要确认。WAL 不会因为产品页写得漂亮就变轻。
接下来最该看的，不是谁在一张榜上多赢几千 TPS，而是三件事：ClickHouse 在打开 HA 后还能保留多少优势；同等价格下 TPS 和 P99 怎么变；其他厂商会不会用更清晰的存储路径指标回应。
对架构负责人来说，结论很朴素：写密集、延迟敏感，就把 PostgresBench 当压力测试模板；重 HA、跨区恢复和托管成熟度，就把它当问题清单。
跑分会说话，但只会说它被安排说的那一段。真正的选型，要让自己的业务负载开口。