Postgres撑到极限后，没人真离开它

Postgres用了三十年，把自己变成了关系型数据库的事实标准。但当业务真的跑起来、数据从几个GB涨到几个TB、并发从几十个连接涨到几千个，几乎所有团队都会撞上同一堵墙。有趣的是，撞墙之后大家的出路出奇一致：不是换掉Postgres，而是重新安排它的位置。这不是一次技术选型的摇摆，而是数据平台架构的一次静默分层——事务归Postgres，分析归列存引擎，中间用管道缝合。

📉 单机的尽头，不是换数据库

每个数据工程师都见过那个下午：大促流量一进来，PostgreSQL 主库CPU先红，然后是连接数打满，应用层报错刷屏，DBA在群里说"先扩个只读副本"。

这不是产品失败，而是负载结构变了。原生Postgres的核心设计假设是"一台足够强的机器"：单机存储、单机计算、MVCC靠vacuum回收垃圾。这些假设在事务负载下极其高效——效率高、行为可预期，这也是它成为默认选择的原因。但它的短板在规模上去之后会集中爆发：

• 连接风暴：每个连接都是进程级开销，应用微服务化之后，连接数轻松破千，主库光是维护连接就疲于奔命；
• 复制延迟：读写分离是第一反应，但副本回放跟不上主库写入速度时，"读旧数据"会从偶发变成常态；
• vacuum与长事务： analytical风格的聚合查询一旦跑在主库上，长事务拖住vacuum，表膨胀雪上加霜；
• 全表扫描：行存天然不适合"扫一亿行、聚合十列"的报表需求，主库CPU被分析查询打满，事务跟着遭殃。

据多位接近大型互联网团队的人士透露，很多团队的第一反应仍是"再买更强的机器"——垂直扩容能续命，但单位成本曲线很快就变得难看。

关键判断在这里：这堵墙不是Postgres的失败，而是OLTP和OLAP这两类负载的本质差异。 用同一个引擎同时伺候两类脾气完全相反的负载，本来就是不现实的期望。

🧩 留在Postgres，但换一种用法

"You can outgrow vanilla Postgres without abandoning Postgres"——这句话的工程含义比标题看起来更丰富：所谓"原生撑不住"，指的是未经改造的部署形态，而不是Postgres这个内核。

业界沉淀下来一套渐进路径，每一层解决一个具体症状：

注意最后一行。它是整套路径的分水岭：前四招都在"把Postgres往大做"，第五招是第一次承认有些负载不该由Postgres来扛。变更数据捕获（CDC）把事务库里的每一笔变更流式外送，交给专门的引擎去做扫描和聚合——主库瞬间清爽，事务延迟恢复稳定。

一个典型团队的演进路径，几乎可以画成一条时间线：

产业逻辑很清晰：Postgres的统治力没有削弱，反而在被强化——它退出了自己不擅长的战场，把全部精力留给最擅长的事务场景，成为整个平台"唯一的真相源头"。越分层，它越稳。

⚡ 实时分析，是另一场战争

分析负载被剥离出来之后，问题变成了：交给谁？

The New Stack 引用的CostBench基准给出了一组扎眼的数字：在"从新鲜数据到达到快速返回答案"的完整链路上，ClickHouse Cloud 相比 BigQuery 交付了每美元438倍的性能。这个倍数哪怕打个对折，也足以让每一个数据平台的预算决策者坐直身子。

差距从哪来？从素材给到的链路视角拆开看，答案藏在"新数据进来"和"答案出去"两端：

• 数据新鲜度链路：实时分析的前提是数据尽快可查。列存引擎的写入路径是围绕持续摄入设计的，数据落地即可参与查询；而以批处理起家的serverless数仓，天然存在微批的惯性，新鲜度与查询响应之间存在结构性时延。
• 查询执行链路：面向事务优化的行存引擎处理"扫全表、聚合几列"的查询时，要把整行数据读出来再丢弃大部分列，I/O放大气人；列存只读需要的列，配合向量化执行，扫描效率完全不在一个量级。
• 成本模型差异：单位成本性能（performance per dollar）是一个复合指标，它同时惩罚"单位查询的资源消耗"和"为保持随时可查而付出的常驻开销"。两个体系在这两项上的取舍根本不同。

一位数据平台负责人的说法在业内私下流传："BigQuery赢在不管运维，ClickHouse赢在跑得快还便宜，问题是你想买哪一头。"这句话未必精确，但点破了一个事实——438倍不是一个孤立数字，而是两套架构哲学在实时分析这一特定战场上的比分。

更要紧的产业信号是：分析型数据库正在从"够用就行"变成成本竞技场。当基准测试开始以"每美元"为单位对比，说明买家的痛点和厂商的竞争焦点，都已经从功能转移到了单位经济性上。

🔀 分层，才是这个时代的正确答案

把前两节的判断拼起来，一个成熟数据平台的形态已经呼之欲出——不是"换掉Postgres"，也不是"Postgres什么都干"，而是一张分工明确的架构图：

这张图的每一层都各取所长：

• 事务层：PostgreSQL 只做OLTP，强一致、低延迟、写入稳，它是全平台唯一可信的写入源头；
• 管道层：CDC把变更以流的方式持续外送，事务和分析的耦合被这条管道物理切断；
• 分析层：列存引擎承接实时看板、用户行为分析、运营报表，以CostBench证明的单位成本性能吃下重扫描负载；
• 湖仓层：历史明细沉淀到湖仓，服务长周期回溯和训练数据准备。

有耐心读到这里的人会发现，所谓"Postgres撑不住"的叙事，其实是个伪命题。真实发生的事情是：数据平台从"一个数据库包打天下"进化成了"事务内核＋分析外设"的分层结构。在这个结构里，Postgres不是被替代了，而是被放到了它效率最高的位置上——并且因为这个位置足够关键，它比以往任何时候都更不可或缺。

结语

原生Postgres撞墙，撞出的是整个数据平台的重新分工。往后看，这条分层路线只会走得更深：事务侧，Postgres生态持续把"连接、复制、扩展"这些老问题工程化；分析侧，单位成本性能的军备竞赛才刚开局，438倍这个数字会逼着每一家云数仓重新回答"你的钱花在哪"。对工程师而言，下一个架构评审里最值钱的问题，已经不是"用什么数据库"，而是"这条负载，凭什么让这个引擎来扛"。