PG 实时湖仓新丁: pg_duckpipe

digoal2026年04月30日约 8 分钟

本期播客

PG 实时湖仓场景又填新丁: pg_duckpipe

还记得被Databricks收购的mooncake、moonlink开源项目吗? 都是诞生自这种场景：
业务库明明跑得好好的，一到 BI、报表、运营分析、风控大盘一起上，PostgreSQL 就开始喘。
加只读副本，治标不治本；上 Kafka + Debezium + 湖仓，架构一下子重到让团队想辞职。
现在，事情可能有了第三条路： 就在 PostgreSQL 里，把行存事务表实时“变身”为列存分析表。

不好意思, 这个赛道又填新丁了: pg_duckpipe

一句话说透 pg_duckpipe：它不是“再造一个数仓”，而是把“数据搬运”这件事砍到最小

过去大家搞 PostgreSQL 分析加速，常见路径只有两条：

第一条，硬扛。
交易和分析都在同一套 heap 表上跑，索引越加越多，SQL 越写越怪，最后是 VACUUM、膨胀、缓存命中率和慢查询一起上头。

第二条，外迁。
把变更流吐给 Kafka、Debezium、Flink、Spark、对象存储、数仓，再建一整套同步、监控、补偿、治理链路。体系很强，但对大量中小团队、单体业务、或者“只想先把实时分析跑起来”的团队来说，实在太重。

pg_duckpipe 的核心价值，就在于它试图走第三条路：
基于 PostgreSQL 的 WAL + logical replication，把普通事务表的变更实时同步到 DuckLake 列式表，并且尽量不引入 Kafka、Debezium、外部编排器这些额外基础设施。原作者给出的定义很直接： 一条 SQL 启动同步，持续把 heap 表同步成面向分析的列式副本。

这事为什么重要？

因为它打中的，不是“数据库功能点”，而是一个长期存在的架构矛盾：

OLTP 追求的是小事务、随机写、低延迟。OLAP 追求的是大扫描、聚合、压缩、吞吐。
让同一种物理存储同时把这两件事都做到极致，本来就违背第一性原理。

PostgreSQL 的 heap/row-store 天生更适合事务型访问；而 DuckDB/DuckLake 背后的列式执行与 Parquet 这种列式格式，本来就更适合分析型扫描、聚合与压缩。DuckDB 官方明确强调其是columnar-vectorized query execution engine，Parquet 官方也明确把自己定义为column-oriented格式。

所以， pg_duckpipe 真正解决的不是“能不能同步数据”，而是“能不能以足够小的架构代价，把事务负载和分析负载物理分层”。

DBA 最该关注的，不是“新技术”，而是“少几层运维负担”

对于数据库管理员、架构师来说，最敏感的从来不是新名词，而是三个问题：

第一，链路是不是短。
链路越长，故障点越多。
Kafka 宕一下、Connector 卡一下、Schema Registry 飘一下、下游任务堆一下，整条链都会变脆。

而 pg_duckpipe 的设计思路是：
直接从 PostgreSQL 的 WAL 逻辑复制流取数，解码后按表分发，再批量写入 DuckLake 列表。
它基于 PostgreSQL 标准 logical replication/pgoutput 协议，这不是黑魔法，而是 PostgreSQL 官方长期支持的复制机制。

第二，故障面是不是可控。
pg_duckpipe 文章里提到几个对 DBA 很关键的设计点：

按表隔离状态机：每张表独立经历 SNAPSHOT、CATCHUP、STREAMING，某一张表出问题，不会把所有表一起拖死。
背压控制：写入列存侧跟不上时，会暂停消费 WAL，而不是让内存无边界堆积。
崩溃恢复：按表跟踪 LSN，采用幂等的 flush 路径，保证至少一次投递下的正确重放。

这意味着什么？
意味着它的思路不是“功能先上”，而是明显带着数据库内核工程的味道： 先考虑状态、顺序、一致性、恢复。

第三，接入门槛是不是低。
PostgreSQL 官方要求 logical replication 的前提包括 wal_level = logical，以及足够的 replication slots / senders。pg_duckpipe 的 README 进一步写明：目前测试版本是 PostgreSQL 18，源表需要 PRIMARY KEY，并且要预加载相关扩展。

这说明两件事：

一件是好消息：
它没有绕开 PostgreSQL 的规则，而是站在 PostgreSQL 官方机制之上。

另一件是必须说清的现实：
这不是“零门槛通用神器”，而是一项处于快速演进中的新能力。
尤其是对生产环境极度保守的团队，版本支持、DDL 传播、观测能力和运维工具链，仍然要谨慎评估。原文路线图也明确写了：后续还在补 schema DDL propagation、broader PostgreSQL version support、per-table lag metrics 等能力。

对应用开发者来说，这玩意儿最大的价值不是“快”，而是“终于不用和 DBA 抢库了”

很多应用开发者都经历过这种尴尬：

一个运营报表要 GROUP BY + ORDER BY + LIMIT
一个风控规则要扫近 7 天订单
一个推荐特征要跑实时聚合
一个产品经理要“再加三个维度看看”

结果呢？
你明知道这些查询不该打在主事务表上，但现实里没有现成分析副本，于是只能：

加各种奇怪索引；
写各种物化中间表；
半夜跑 ETL；
最后把业务库搞得越来越像四不像。

pg_duckpipe 提供的方向，本质上是：

让开发者继续往 PostgreSQL 事务表写；让分析查询落到列存副本上。

这件事的价值，不只是“查询可能更快”，而是职责边界终于更清楚了：

事务表负责正确写入、约束、更新；
列式表负责扫描、聚合、报表、宽查询；
CDC 负责把两边接起来。

这就是典型的读写路径分离。
不是代码层的分离，是物理存储与执行路径的分离。

原项目给出的使用方式也非常克制：
本地表同步只需要 duckpipe.add_table('public.orders')；
远端 PostgreSQL 只要支持 logical replication、提供复制用户，也能拉取同步，不要求源库安装 pg_duckpipe/pg_ducklake。

对开发团队而言，这意味着很现实的一点：

你不一定要改业务，不一定要引入消息总线，不一定要重建数仓流程，就能先把“实时分析副本”跑起来。

这东西值不值得上？先看前提，别一上来就神化

我最反感的一种技术文章，就是上来一句“革命性突破”，然后默认所有业务都适用。
这不严谨。

结论先说：

pg_duckpipe 只有在下面这组前提成立时，才真正有杀伤力：

你的主系统就是 PostgreSQL；
你确实同时有事务负载和分析负载；
分析查询以聚合、扫描、多维统计为主，而不是单点查主键；
你希望数据尽量新鲜，最好是秒级，而不是 T+1 批处理；
你又不想为了这件事先上整套 Kafka/CDC/流计算平台。

如果这五条同时成立，
那 pg_duckpipe 的价值非常直接： 用更短的技术路径，换来事务和分析分层。

但如果前提崩塌，结论要立刻改：

如果你的分析需求很弱，
一天就几张简单报表，完全没必要引入新扩展。
定时 ETL、物化视图，甚至只读副本，可能就够了。

如果你的业务规模已经进入多系统、多源异构治理阶段，
要统一接 Oracle、MySQL、SaaS、日志流、对象存储，再做全域血缘、治理、回放、审计，
那 pg_duckpipe 就不是主角。
这种场景里，成熟 CDC 平台和数仓/湖仓体系仍然有不可替代的位置。

如果你对生产稳定性要求极端苛刻，
尤其需要长期版本支持、成熟观测、严格变更管理、清晰 SLA，
那就必须看到一个现实：
当前 pg_duckpipe 还处于早期阶段，README 写得很诚实——目前只测试 PostgreSQL 18，路线图里还有 DDL 传播、观测和性能增强在推进。

换句话说：

它今天更像一把锋利的新刀，不是所有团队都该立刻拿它切生产。
但它代表的方向，非常值得认真看。

为什么我认为它踩中了 PostgreSQL 生态接下来几年的一个大趋势？

因为 PostgreSQL 生态这几年最明显的变化，不是“再做一个功能”，而是：

越来越多人想把 PostgreSQL 从“单纯事务库”推进成“应用数据底座”。

这背后有两个现实驱动力。

现实一：团队不想再为“多一类查询”就多养一套系统

每加一套中间件，都不是“多一个组件”那么简单，
而是多一套监控、升级、备份、容灾、权限、值班和故障处理逻辑。

所以今天大家越来越在意的，不是功能绝对最强，而是：

能不能更少组件完成目标；
能不能在熟悉的 PostgreSQL 体系内完成更多事情；
能不能让 DBA、开发、数据团队用同一套元数据和权限体系协同。

现实二：数据新鲜度正在变成默认要求

很多业务已经不是“第二天看报表”了，
而是：

今天的转化漏斗，马上要看；
刚写入的订单，马上要进风控；
新产生的事件，马上要进分析和推荐；
运营看板延迟 1 小时，业务都嫌慢。

在这种背景下， 批处理 ETL 的问题不是不能用，而是越来越不够用。

PostgreSQL 官方 logical replication 本来就支持初始同步加后续增量复制；pg_duckpipe 只是把这个能力，延伸到了“面向分析的列式副本”场景。

这就是它最聪明的地方：
不是重新发明同步，而是把 PostgreSQL 已有复制机制，接到了一个更符合分析负载的存储形态上。

这里有个细节，很多架构师一眼就会意识到它的分量

pg_duckpipe 不是只能同步本地库。
原文明确提到： 它可以从远端 PostgreSQL 复制，源库不需要安装 pg_duckpipe 或 pg_ducklake，只需要 wal_level = logical 和复制用户。

这意味着什么？

意味着它的潜在应用，并不只是“我本机开一个扩展试试”，而是：

给现有生产 PostgreSQL 外挂一个实时分析层；
不碰现网业务 SQL；
不强迫源库引入新扩展；
先在旁路场景做增量验证。

对很多企业架构来说，这比“重构主系统”现实得多。
因为真正难的从来不是“技术能不能做”，而是能不能以最小业务风险做起来。

数据和案例怎么看？别吹神话，看边界

项目 README 给出了一个基准测试：
在 Apple M1 Pro、10 万行/表、30 秒 Sysbench OLTP 场景下，不同测试中同步吞吐达到约 13 万到 16 万 rows/s，并给出了对应 lag 数据，结果标记为 PASS。

这个数字能说明什么？

能说明两点：

第一，它不是 PPT。
至少项目已经在用标准 OLTP 基准对自己的 CDC 路径做压测。

第二，它还不是行业标准答案。
因为这类 benchmark 依赖硬件、表结构、事务模式、flush 策略、并发度、主键分布、宽表程度等太多条件。
你不能把一个仓库 README 里的测试，当成对所有生产环境的普适承诺。

所以严谨的说法应该是：

它已经证明“这条路走得通”，但没有任何人应该在没做自家压测前，就把它当成现成银弹。

这才是 DBA 和架构师该有的专业判断。

最后给两类人各一句判断

给 DBA / 架构师：

如果你正在被“业务库既要扛交易又要扛分析”折磨，
又不想立刻把系统复杂度拉到 Kafka + Debezium + 全家桶级别，
pg_duckpipe 值得你认真评估。

它代表的是一种更轻、更短、更符合 PostgreSQL 生态习惯的 HTAP 实现路径。
但请记住： 它今天更适合试点、旁路、分析加速场景，不适合闭眼上核心生产。

给应用开发者 / 数据库用户：

如果你总在主库上写那些“自己都觉得不该跑在主库上”的大查询，
那你该高兴了。
这类技术的真正意义，是把你从“为了报表去污染事务模型”的困境里解放出来。

你写业务，数据库做事务；
分析要快，走列存副本；
同步交给 CDC。
这才是分工清楚的系统。

结尾

说到底，pg_duckpipe 最有意思的，不是它又给 PostgreSQL 加了一个新扩展，
而是它在提醒整个生态一件事：

未来的数据架构，未必总是“更多系统”，也可能是“更短路径”。
谁能用更少的组件，把事务、分析、新鲜度和运维复杂度平衡好，谁就更接近现实世界的最优解。

你怎么看？
你更看好这种“PostgreSQL 内部轻量 HTAP”路线，
还是更相信 Kafka + CDC + 湖仓全家桶这套重装架构？
欢迎在评论区聊聊，你现在的库，到底是被交易压垮，还是被分析拖慢。