438倍差距，撕开实时分析的账单

最近数据圈的两条消息值得放在一起看：一边，越来越多团队发现原版 Postgres "撑不住"了，但几乎没人真的想搬家；另一边，CostBench 基准测试给出一个刺眼数字——ClickHouse Cloud 比 BigQuery 每美元性能高出438倍。两件事看似无关，其实指向同一个趋势：💰 数据架构的竞争，正在从功能叙事转向账单叙事。今年买数据库，先看账本，再看PPT。

📉 Postgres的甜蜜烦恼：好用，好用出事了

数据库选型从来没有弯路，只有必经之路。

先讲一个常见场景。一家做SaaS的创业团队，MVP阶段把所有东西都塞进 Postgres——用户、订单、日志、报表。产品跑得飞快，团队不需要学任何新东西。第二年客户翻了几十倍，报表查询开始拖垮主库，写入高峰队列堆积，DBA半夜被告警叫醒。

这不是个案。Postgres 之所以成为关系型数据的事实标准，是因为它高效、直接、可靠，开发者几乎不需要做取舍。但正因为它太好用，团队会不假思索地把一切负载都压上去，直到某一天撞上单机天花板。

压力点通常集中在三处。一是连接数与并发，长连接一多，内存和进程调度先出问题；二是写入吞吐，单机日志和索引维护存在物理上限；三是分析查询，一条全表扫描的报表SQL，能把在线交易的延迟整个拖垮。

产业逻辑在这里非常清晰：Postgres 的问题从来不是"不好"，而是"太成功"。它承载的业务越多，暴露的短板越具体；而短板越具体，解决方案反而越清晰。这和那些业务还没跑通就急着上分布式的团队，恰好是两个相反的错误方向。

🧩 不搬家的扩容：Postgres生态的三条路

真正的架构成熟，是知道什么时候不换引擎。

The New Stack 那篇文章的标题其实已经给出结论：你可以"长大"到超出原版 Postgres 的能力，但不必离开 Postgres。这是过去两年数据库生态里最务实的一条路线。

具体拆开，扩展路线大致有三条。第一条是垂直与读扩展：加内存、上只读副本，把报表和重查询分流出去，成本最低，见效最快。第二条是拆分：表分区、按业务拆库，再往后是分布式扩展，把写压力摊到多个节点。第三条是"外挂"专长引擎：时序扩展管监控数据，列存和向量化扩展管分析查询，让分析负载不碰主库。

值得注意的是压力的演进节奏。多数团队是被业务一步步推着走到第三条路的——

这套"原地长高"的打法之所以成立，是因为 Postgres 的协议和SQL方言已经成为生态的默认接口。换掉它，意味着重写ORM、迁移工具链、重训团队，这笔隐性成本往往比数据库本身贵一个数量级。据多位接近中型互联网公司的人士透露，如今技术评审会上"不换Postgres"几乎成了默认前提，讨论重心全在旁边加什么。

⚡ 438倍：这笔账是怎么算出来的

基准测试的价值不在绝对数字，而在它逼你算账。

ClickHouse Cloud 与 BigQuery 在 CostBench 上的对比，The New Stack 给出的结论是：实时分析场景下，每美元性能差距达到438倍。这个数字需要冷静看——基准测试通常由一方厂商主导，口径永远存在偏向，438倍也不该被理解为所有负载的普遍差距。

但真正有信息量的不是倍数本身，而是归因方式：差距被沿着"从新数据到达，到快速答案返回"的整条链路逐段拆解。💰 实时分析的成本，藏在每一个环节的抽象税里。

链路的每一环，两边的工程哲学都不同。专用分析引擎从存储层就是列式，压缩比高、扫描快，天然为"同样的数据反复聚合"这类负载而生；而全托管数仓把弹性、多租户和易用性做进了每一层，便利是真的，便利的账单也是真的。

产业逻辑上，这不是一次简单的性能对比，而是两种商业模式的对撞。专用引擎卖的是"把一件事做到极致"，全托管平台卖的是"你什么都不用管"。当实时分析从低频操作变成常态负载，当客户开始逐行审查账单，后者的定价模型会持续承压。438倍未必精确，但方向大概率是对的。

🏗️ 全托管与专用引擎，正在各走各路

易用性是云的护城河，也是云的定价权。

把两条线合起来看，市场正在分岔。一条路以 BigQuery、Snowflake 为代表：全托管、存算分离、按量计费，目标是让数据团队不养运维。另一条路以 ClickHouse 为代表：专用存储格式、极致单查询性能，目标是把高吞吐负载的单位成本压到最低。

场景化理解更直观。一家电商大促期间要做实时大屏，数据持续涌入、查询持续高频——这是专用引擎的主场，单位成本低就是硬道理；同一家公司月底跑一次全量归因分析，一年几十次——全托管按量付费反而便宜，还不用常备资源。

据多位接近云厂商的人士透露，近一年大客户续约时对分析账单的审查明显变严，FinOps团队开始直接参与数据平台选型。这在两三年前还很少见。

产业判断：两个阵营不会谁消灭谁，但边界会越来越清楚。实时、高频、可预测的负载流向专用引擎；低频、多样、突发的负载留在全托管平台。真正危险的是中间地带——负载画像模糊的团队，最容易为错误的假设连付三年的钱。

💡 给选型者的三句话

架构选型的本质，是为已知负载买对工具。

第一句，负载优先于品牌。先把QPS、数据新鲜度要求、查询模式写成数字，再去看产品。市面上多数选型争论，源于双方说的根本不是同一种负载。

第二句，TCO替代标价。438倍是每美元性能，不是每美元总成本——还要算上人力、迁移、锁定风险。但反过来说，规模一旦上去，引擎效率的差距最终一定会穿透运维成本的缓冲，而不是被它永久吸收。

第三句，Postgres不必抛弃，但要舍得"外挂"。核心交易库继续用 Postgres，把时序、检索、实时分析这些异构负载交给旁边的专用引擎，主库只做它最擅长的事。这是当下性价比最高、返工成本最低的架构形态。

小结

Postgres 的"撑不住"和438倍的差距，讲的是同一个故事：数据规模和实时性要求上来之后，任何单一引擎都会在某个环节露出成本短板。未来的赢家不是某个全能数据库，而是分层架构——Postgres 守住事务核心，专用引擎吃掉实时分析，账单上每一分钱都对应清晰的负载画像。下一轮竞争的焦点，不再是"谁能做更多"，而是"同样的负载，谁能让你付得更少"。