数据库火星撞地球:当PG爱上DuckDB


蹭热点引出的好话题

昨晚在直播间,我与几位国内 DuckDB 先锋进行了一场对谈。 话题跨度很大,从 DeepSeek 团队在开源周推出的分布式 DuckDB 分析框架 “Smallpond”,聊到 PostgreSQL 与 DuckDB 的深度融合,相当热闹。

DeepSeek 的开源的 “小池塘”用把 DuckDB 改为分布式的用法,从营销上给 DuckDB 打了很好的广告。 但从实用角度和影响力来说,我个人对分布式 DuckDB 的价值保持保留态度(那个3FS实际上更有用)。 因为这与 DuckDB 本身的核心价值主张(大数据已死)完全背道而驰。

那么如果不去折腾 “分布式”,DuckDB 未来更有前景的方向是什么? 相比之下,我更加看好 “ DuckDB + PostgreSQL深度融合” 这路径。 我甚至认为,它可能会引爆数据库世界下一场“火星撞地球”式的变革。


DuckDB:OLAP挑战者

DuckDB 由 Mark Raasveldt 和 Hannes Mühleisen 在荷兰的 CWI (国家数学与计算机科学研究所)开发 —— 而 CWI 不仅仅是一个研究机构,可以说是分析型数据库领域发展背后的幕后推手与功臣,是列式存储引擎与向量化查询执行的先驱。

现在你能看到的各种分析数据库产品 ClickHouse,Snowflake,Databricks 背后都有它的影子。 而现在这些分析领域的先锋们自己亲自下场来做分析数据库,他们选择了一个非常好的时机与生态位切入,搞出了一个嵌入式的 OLAP 分析数据库 —— DuckDB

DuckDB 的起源来自作者们对数据库用户痛点的观察:数据科学家主要使用像 Python 与 Pandas 这样的工具,不怎么熟悉经典的数据库。 经常被如何连接,身份认证,数据导入导出这些工作搞的一头雾水。那么有没有办法做一个简单易用的嵌入式分析数据库给他们用呢?—— 就像 SQLite 一样。

DuckDB 整个数据库软件源代码就是一个头文件一个c++文件,编译出来就是一个独立二进制,数据库本身也就一个简单的文件。 使用兼容 PostgreSQL 的解析器与语法,简单到几乎没有任何上手门槛。尽管 DuckDB 看上去非常简单,但它最了不起的一点在于 —— 简约而不简单,分析性能也是绝冠群雄。例如,在 ClickHouse 自己的主场 ClickBench 上,有着能够吊打东道主 ClickHouse 的表现。

同时,DuckDB 使用极为友善的 MIT 许可证开源:一个有着顶尖性能表现,而使用门槛低到地板,还开源免费,允许随意包装套壳的数据库,想不火都难


取长补短的黄金组合

尽管 DuckDB 有着顶级的分析性能,但它也有自己的短处 —— 薄弱的数据管理能力, 也就是数据科学家们不喜欢的那些东西 —— 认证/权限,访问控制,高并发,备份恢复,高可用,导入导出,等等等, 而这恰好是经典数据库的长处,也是企业级分析系统的核心痛点。

从这个角度来说,duckdb 更像是 RocksDB 这样的底层 “存储引擎”,一个 OLAP 算子。 本身距离一个真正的 “数据库” / “大数据分析平台” 还有很多工作要做。

PostgreSQL 则在数据管理领域深耕多年,拥有完善的事务机制、权限控制、备份恢复和扩展机制。 传统的 OLTP 场景下 PostgreSQL 更是 “老牌猛将” 。 但 PostgreSQL 的一个主要遗憾就是:尽管PostgreSQL 本身提供了很强大的分析功能集,应付常规的分析任务绰绰有余。 但在较大数据量下全量分析的性能,相比专用的实时数仓仍然有些不够看。

clickbench.png

那么人们自然而然会想到,如果我们可以结合两者的能力,PostgreSQL 提供全面的管理功能与生态支持,以及顶级的 OLTP 性能。 DuckDB 提供顶尖的分析算子和 OLAP 性能;二者深度融合,就能把各自优势叠加,取长补短,在数据库领域中产生一个“新物种”。

DuckDB 能很好的解决 PostgreSQL 的分析短板,甚至还可以通过读写远程对象存储上的 Parquet 等列存文件格式,实现无限存储的数据湖仓的效果;而 DuckDB 孱弱的管理能力也通过融合成熟的 PostgreSQL 生态得到完美解决。 比起给 DuckDB 套壳,搞一套什么新的 “大数据平台/数据管理系统”,或者给 PostgreSQL 发明一个新的分析引擎,两者融合起来,取长补短,是一条阻力最小,而价值最大的道路。

实际上,这正是数据库世界中正在发生的事情,许多团队和厂商已经投入到 DuckDB + PostgreSQL 的缝合当中,试图率先抢得这个潜力巨大的新市场。


群雄逐鹿的缝合赛道

当我们把目光投向业界,不难发现 已经有诸多玩家入局了

最早进入这条赛道的是国内个人开发者李红艳开发的 duckdb_fdw,一直算是不温不火的状态。 然而在 《PostgreSQL正在吞噬数据库世界》以向量数据库的例子预言了 OLAP 赛道的机会之后, PG 社区对征服 OLAP 缝合 DuckDB 的热情被彻底点燃。

duck-star.png

就在 2024 年 3 月的时间点上,一切骤然加速。ParadeDB 的 pg_analytics 插件立即切换了技术路线,改为缝合 DuckDB。

PG 生态发起 pg_quack 项目的 HYDRA 与 DuckDB 母公司 MotherDuck 开始合作,发起了 pg_duckdb。 官方开始下场, “不误正业” 地不去折腾 DuckDB,反而搞起了 PostgreSQL 插件。

接下来,在数据库热点上一向嗅觉敏锐的 Neon 赞助了 pg_mooncake 项目,这个新玩家选择站在 pg_duckdb 的肩膀上, 不仅要把 DuckDB 的计算能力给缝合入 PG,还要将 DuckDB / Parquet 开放分析存储格式原生融合到 PG 的表访问接口中,把存储和计算能力一起缝合到 PG 中。

一些头部云厂商,比如 阿里云rds 也在尝试缝合包装 DuckDB,标志着已经有大玩家开始忍不住准备下场了。

这种场面很容易让人联想到早两年的“向量数据库热”。当 AI 检索和语义搜索成为热点,不少厂商都“闻风而动”,基于 PostgreSQL 开发向量数据库插件, AI爆火之后,PG 生态里就涌现出了至少六款向量数据库扩展( pgvectorpgvector.rspg_embeddinglaternpasepgvectorscale), 并在你追我赶的赛马中卷出了新高度。

最后 pgvector 在以 AWS 为代表的厂商大力投入加注之下,在其他数据库比如 Oracle / MySQL / MariaDB 的糊弄版本姗姗来迟之前, 就已经把整个专用向量数据库细分领域给荡平了,吃下了 RAG / 向量数据库带来巨大增量里的最大蛋糕。而现在,似乎是这种赛事在 OLAP 领域的又一次预演。


为什么是DuckDB+PG?

比较有趣的一点是,这样的奇景同样只出现在 PostgreSQL 生态中,而在其他数据库社区中依然一片寂静。 甚至 DuckDB 官方也在参加 PostgreSQL 缝合大赛,而不是其他什么 DB 的缝合大赛。

所以有人会问:既然要跟 DuckDB 融合,为什么不选 MySQL、Oracle、SQL Server 甚至 MongoDB? 难道这些数据库就没有管理能力,不需要取长补短,不能跟 DuckDB 融合,获取顶级 OLAP 能力吗?

PostgreSQL 与 DuckDB 是一对完美的组合,体现在三点上:功能互补,语法兼容,可扩展性:

首先,DuckDB 使用的是 PostgreSQL 语法,甚至语法解析器都是直接照搬 PG 的, 这意味着两者关键接口的差异性非常小,天然具有亲和力,也就是不怎么需要折腾。

第二,PostgreSQL 和 DuckDB 这两个数据库均是公认的“可扩展性怪物”。无论是 FDW、插件,还是新存储引擎、新类型,都能以扩展的形式接入。 比起魔改 PG + DuckDB 的内核源码,写一个粘合两边现有接口的扩展插件显然要简单太多了,

extensibility.webp

这种天生的技术血缘亲和力,让 “PG + DuckDB” 的融合成本显著低于所有其他组合,低到李老师这样的独立个人开发者都可以参赛(顺势而为是好事,无任何贬义)。

与此同时 PostgreSQL 是世界上最流行的数据库,也是主要数据库中唯一有增长而且是高速增长的玩家,缝合 PostgreSQL 带来的收益也要比其他数据库大得多。

这意味着,“PG + DuckDB” 的融合,是一条“阻力最小、价值最大”的康庄大道,大自然厌恶真空,因此自然会有许多玩家下场来填补这里的空白生态位。


统一 OLTP 与 OLAP 的梦想

在数据库领域,OLTP 与 OLAP 的分裂由来已久。所有的“数据仓库 + 关系型数据库”架构、ETL 和 CDC 流程,都是在修修补补这道裂痕。 如果 PostgreSQL 在保留其 OLTP 优势的同时,能嫁接上 DuckDB 的 OLAP 性能,企业还有必要再维护一套专门的分析数据库吗?

这不仅意味着**“降本增效”**,更可能带来工程层面的简化:无需再为数据迁移和多数据库同步烦恼,也无需支付昂贵的双套维护成本。 一旦有人把这件事做得足够好,就会像“一颗深水炸弹”般冲击现在大数据分析的市场格局。

PostgreSQL 被视为“数据库界的 Linux 内核” —— 它的开源精神和极强的可扩展性允许无限可能。 而我们目睹着 PostgreSQL 使用这种方式,依次占领了地理信息,时序数据,NoSQL文档,向量嵌入等领域。 而现在,它正准备向最后也是最大的生态位 —— OLAP 分析领域发起冲击。

只要一个优秀的集成方案出现,能让 DuckDB 提供的高性能分析与 PostgreSQL 的生态完美融合,整个大数据分析领域或许会因此大变天。 那些专门的 OLAP 产品,能否顶住这场“核爆级”冲击?是否会像那些 “专用向量数据库” 一样凋零, 现在没人愿意给出答案,但我相信到时候大家都会有自己的判断。


为PG与DuckDB缝合铺好路

PostgreSQL OLAP 生态的现状,正如同两年前的向量数据库插件一样,还处于早期阶段。 但这已经足够令人兴奋:新技术的魅力就在于,你能预见它的潜力,就能率先拥抱它的爆发。

两年前 PGVECTOR 爆火前夜,Pigsty 是第一波将其整合的 PostgreSQL 发行版,也是我将它提入 PGDG 官方扩展仓库的。 而这场 DuckDB 缝合大赛,干脆就是我点的火。能点燃这样的赛事,我自然也会在这场新的赛事中,提前为 PG 与 DuckDB 的融合铺好路。

作为一名深耕数据库领域的从业者,我正在把当前各家与 DuckDB 融合的 PostgreSQL 插件 全部打包成可直接安装使用的 RPM 或 DEB 包,并在主流的十个 Linux 发行版上提供, 与 PGDG 官方内核完全兼容,开箱即用,让普通用户也能轻松体验“DuckDB + PG”融合的威力。 最重要的是,提供一个缝合大赛的“竞技舞台”,让所有玩家都平等参与进来。

诚然,现在不少插件仍处于早期阶段,稳定性和功能尚未达到“企业级”的标准。也有很多细节待完善,比如并发访问控制、数据类型兼容、算子优化等。 机会总是属于勇于拥抱新技术的人,而我相信,这场“PG + DuckDB”融合的大戏,将会是数据库领域的下一个风口。


真正的爆炸即将开始

比起当下 AI 大模型落地在企业应用中仍显“虚浮”的热潮,OLAP 大数据分析 是一块更为庞大、也更现实的市场蛋糕。 而 PostgreSQL 与 DuckDB 的融合 则有望成为冲击这个市场的板块运动,引发行业格局的深度变革,甚至彻底打破“大数据系统 + 关系型数据库”两套架构并行的局面。

或许再过几个月到一两年的时间,我们就能看到一个或多个“融合怪物”从这些实验性项目中脱颖而出,成为数据库的新主角。 谁能先解决好扩展的易用性、集成度和性能优化,谁就能在这场新竞争中夺得先机。

对于数据库行业而言,这将是一次“火星撞地球”般的深度震荡;对于广大企业用户而言,或许会迎来一场“降本增效”的巨大机遇。 让我们拭目以待这场新趋势如何加速成长,并为数据分析与管理带来新的可能。

最后修改 2025-03-14: update homepage (c4b8230)