ClickHouse闯进Postgres的主场

一个以分析见长的OLAP引擎，把「帮助Postgres往外搬数据」做成了一门生意。

2025年初，ClickHouse宣布收购PeerDB——一家专门做Postgres CDC（变更数据捕获）的创业公司。随后，其官方数据集成服务ClickPipes中的Postgres连接器正式GA：基于逻辑复制实现初始快照加持续增量同步，支持加列等常见Schema变更的自动跟随，官方博客明确将其定位为「把Postgres数据以最原生的速度接入ClickHouse」的关键一步。而在Postgres Conference、PGConf等TP社区大会上，ClickHouse团队也频繁出现在展台与演讲列表里，围绕「Postgres到ClickHouse」这条管道反复布道。

这个组合乍看有些错位——一边是以极致分析性能著称的列式引擎，一边去事务型数据库的社区里凑热闹。

但错位背后，是当下数据基础设施市场最清晰的一条主线：TP与AP的边界正在溶解，而Postgres成了所有人都绕不开的那个入口。

🗽 搬家生意，开进了Postgres的家门口

赞助墙上的logo排布、展台前的人流密度，往往比官方通稿更诚实。

Postgres Conference是TP社区的核心舞台，参会者画像高度明确：手里管着生产库的DBA、后端工程师、平台架构师——这群人写下的每一笔业务数据，最终都要被上面的老板、运营和分析师反复查询。换句话说，这里聚集的不是竞品的用户，而是分析引擎最上游的数据源头。

ClickHouse选择在这里刷存在感、演示集成，动作本身就是一个判断：AP引擎的获客战场，正在前移到TP的生态里。你在Postgres大会上拿下一个DBA的心智，可能比在十个分析型峰会上投广告更有用。

demos与官方文档也印证了这个思路。ClickHouse讲的并非替代Postgres的叙事，而是一套「接得住Postgres数据」的集成路径，具体到产品层包括：

• ClickPipes Postgres连接器：基于pgoutput逻辑复制，先做一致性初始快照，再切入持续CDC增量同步，官方口径为分钟级以内的端到端延迟；
• Schema变更跟随：对加列等常见DDL自动适配，减少同步管道「一改表就断」的运维痛点；
• 来自PeerDB的积累：并行批量同步、upsert与append-only模式，以及为每行数据附加_peerdb_timestamp等同步元数据的「peer fields」设计；
• 联邦查询兜底：除CDC管道外，还提供直接连接Postgres的表引擎，允许跨库读取，覆盖不需要常驻同步的场景。

这里面的产业逻辑不复杂：分析引擎的竞争已经从「谁算得快」进入「谁离数据源更近、管道铺得更顺」。 计算性能的差距在基准测试里能拉平，但生态位和取数路径一旦固化，就很难被撼动。

🧲 为什么偏偏是Postgres

金句开场：生态的赢家不需要赢下所有场景，只需要成为所有人的默认选项。

过去十年，Postgres完成了一场教科书级别的生态逆袭。从初创公司的第一张表，到大型企业的核心订单库，再到无数SaaS产品的存储底座，Postgres事实上成了新一代应用的「默认事务数据库」。

这不是印象分，是有数据背书的：在Stack Overflow 2024年度开发者调查中，PostgreSQL以48.7%的使用率连续第二年位居所有数据库之首（2023年这一数字为45.55%），超过MySQL的40.3%。与此同时，各云厂商纷纷推出兼容Postgres协议的托管服务——兼容Postgres，几乎成了新数据库产品的标配姿态。

这意味着一件事：企业里最值钱的实时业务数据，越来越多地躺在Postgres里。

而对AP引擎来说，问题随之而来——数据在TP库里，分析却不能在TP库里跑。让一个为高并发小事务设计的行式引擎去扫描亿级明细、跑复杂聚合，成本和体验都会崩掉。于是「数据从Postgres流向分析引擎」这条管道，成了整个现代数据栈里最拥挤的一段路。

这条管道上，方案五花八门：有人在数据库外面挂一套同步工具，有人在中间架一层消息队列，有人干脆用外部数据封装直接跨库查询。路径越多，说明痛点越真，也说明谁的集成做得越省心，谁就能在这段路上收过路费。

ClickHouse收购PeerDB、力推Postgres集成，本质上是在抢这个「过路费」的定价权：让用户觉得，从Postgres到ClickHouse这条路是原生顺滑的、几乎是默认选项，而不是需要额外采购和运维的一堆胶水组件。

🔀 集成而非替代，AP厂商的现实主义

金句开场：最好的进攻姿态，从来不是喊出替代，而是把自己变成对方生态里最顺手的那块拼图。

值得细品的是姿态的分寸。ClickHouse没有讲「换掉Postgres」的故事，而是讲「和Postgres配合」的故事。这不是谦逊，是清醒。

从负载本质看，TP和AP是两种几乎对立的工程取舍，短期内谁也吃不掉谁：

既然如此，与其在对方的腹地硬打，不如把「集成」做成自己的护城河。这背后是一种非常现实主义的产品哲学：AP厂商承认Postgres在OLTP侧的地位，换取的是Postgres用户在分析侧的第一联想。

从更大的视角看，这其实是新一代AP引擎的共同进化方向。过去AP引擎习惯于做「数据栈的终点」——等T+1的ETL把数据送上门。而实时化浪潮改变了游戏规则：业务方越来越不能接受「昨天」，CDC成了标配，分析引擎必须主动伸出手，去事务库的日志里实时捞数据。谁的手伸得越长、抓得越稳，谁在实时分析市场的位置就越靠前。

集成深度，正在变成AP引擎的第二条性能曲线。 第一条曲线是基准测试里的查询速度，第二条曲线是从数据产生到可分析的时延与顺畅度——后者在真实生产环境里，往往更接近客户的付费理由。

⚖️ 竞合时代，账要算在数据流向上

金句开场：判断数据库市场的格局，别看发布会，看数据的流向和账单的归属。

把镜头拉远，这笔收购与这轮「AP引擎进TP社区」的戏码，是数据栈三十年收敛趋势的最新一章。粗暴地划一条时间线：

• 单库时代：一个Oracle包打天下，TP与AP不分家，代价是贵和慢；
• 读写分离时代：主从复制撑起了早期互联网，分析需求靠凌晨跑批；
• 分家时代：分库分表盛行，数据仓库独立成栈，TP与AP彻底各过各的；
• 湖仓与实时时代：AP引擎反向贴近TP生态，CDC管道取代T+1跑批；
• 融合时代：Postgres成为事实上的数据入口，各路引擎围绕它重新站队。

这条线里藏着几个对未来的判断。

第一，Postgres的地位短期无人可撼，它正在从「一个数据库」升维成「一种接口标准」。 这对TP侧是护城河，对AP侧则是流量入口——谁贴得越紧，谁的获客成本越低。ClickHouse收购PeerDB、深耕ClickPipes的Postgres连接器，买的就是这个入口位置。

第二，AP引擎之间的差异化会越来越往「管道体验」上卷。 查询性能的公开差距已经不大，真正拉开体验的是：初始同步有多省事、增量延迟有多低、Schema变更跟不跟得上、出问题好不好排查。这些不性感但决定续费的细节，会成为下一个阶段的竞争主战场。

第三，云厂商的入场让这场竞合更微妙。 各大云都有托管Postgres，也都在推自己的分析产品，中立AP引擎与Postgres生态的「联姻」，某种程度上也是在向云厂商的捆绑销售抢夺话语权。

综合以上动向，可以做出这样的判断：未来几年，数据栈不会走向单一引擎的大一统，而是走向「TP管写入、AP管查询、管道层决定体验」的分工秩序。在这个秩序里，Postgres和ClickHouse不是对手，而是同一条流水线上的上下游工位——只是谁都想在这条流水线上多占一个好工位。

结语

一笔帮Postgres「往外搬数据」的收购，比任何通稿都更值得琢磨。这不是偶然，而是数据基础设施市场给出的明确路标：TP与AP的战争打不起来了，取而代之的是围绕Postgres生态的集成之争、管道之争、入口之争。

对从业者而言，选型时的真正问题已经从「用哪个数据库」变成「数据从产生到可分析，整条链路要经过几个组件、几份运维、几笔账单」。而对厂商而言，下一轮座次排定，看的不再只是基准测试的秒数，还有谁把通往Postgres的那条路，修得最快、最平、最让人离不开。

Postgres的江湖还在扩大，而围绕它的城墙根下，已经站满了排队进场的人。