正文
》专栏中，我已多次聊过这件事了：公有云 PaaS 云软件白嫖开源软件（数据库）的行径是
行业毒瘤
，必将招致反噬 —— 而这将成为这个时代的行业核心议题。比如：
云遣返运动
Databricks vs. Snowflake 的街头帮派混战还在继续
Databricks 和 Snowflake 之间的互怼依然火力全开。这俩大厂的恩怨情仇，绝对是一场“经典数据库之战”，已经从性能打到了生态、从台面斗到了台下。
2024 年 3 月，Databricks 先开了一枪，宣布花了 1000 万美元训练了一个
自家开源大模型 DBRX
[46]
，拥有 1320 亿参数。开发团队就是他们在 2023 年花 13 亿美元收购的
Mosaic
[47]
团队。结果一个月后，Snowflake 也搞了个
Arctic 开源大模型
[48]
，有 4800 亿参数，号称只花了 200 万美元就把它训练得能吊打 DBRX，尤其在“企业场景”诸如自动生成 SQL 方面更强。你能看出 Snowflake 故意把自己跟 DBRX 对比，一副“我就是要怼你 Databricks”的气势；他们甚至承认有其他模型（比如 Llama3）跑得比自己还猛，但就是硬要对比 DBRX。某位 AI 研究员说
为什么Snowflake 天天盯着 DBRX 不放
[49]
，而不跟别的大模型比？他大概不知道这俩数据库厂都流了多少血了。
就在公众都盯着大模型大战时，Databricks 和 Snowflake 又在“元数据目录”这个领域暗自角力。从 2010 年代起，Hive 的
HCatalog
[50]
一直是数据湖上的默认目录服务。后来
Iceberg
[51]
（Netflix 出品）和
Hudi
[52]
（Uber 出品）崛起，这俩都成了 Apache 顶级项目，有不少风投支持的公司在运营。它们主要是做对象存储（如 S3）的元数据服务，实现事务式的数据插入。Databricks 有自家专有的
Unity
[53]
目录，与
DeltaLake
[54]
配合。Snowflake 则在 2022 年宣布
首次支持 Iceberg
[55]
，随后几年进一步
扩展对 Iceberg 的兼容
[56]
。再后来他们打算收购
Tabular
[57]
，也就是 Iceberg 背后最大的公司，以此在目录这一块跟 Databricks 抗衡。据说 Snowflake 差不多谈好了
6 亿美元收购 Tabular
[58]
，结果 Databricks 半路杀入，直接
豪掷 20 亿美元
[59]
把 Tabular 给抢了过来，而且就挑在 Snowflake CEO 主题演讲那天宣布……可怜的 Snowflake 当场尴尬；他们那天才刚宣布一个
Polaris 开源目录服务
[60]
，结果 Databricks 隔天更是雪上加霜，放话要
开源自家的 Unity 目录
[61]
。这下算是给 Snowflake 一记
Murdergram
[62]
。
Andy 的看法：
这场数据库大战已经不只是比谁跑得快那么简单。它不像 90 年代 Oracle 和 Informix 的对轰，那会儿拼的就是 SQL 查询速度。确实，Informix 当年除了做基准测试还
搞了官司
[63]
告 Oracle，说 Oracle 挖他们高管，结果最后自己
撤诉了
[64]
。更惨的是 Informix CEO 后来还被爆出做财务造假，虚报营收指标来显得比 Oracle 牛，最后
被判刑
[65]
坐了两个月牢。
然而 Snowflake 和 Databricks 这一仗，已经扩展到数据库周边生态：从怎么把数据灌进数据库，到接下来怎么处理数据，再到大模型和 AI 路线。这年头，列式引擎跑分析已经算是
大路货
[66]
了，Databricks 和一众 OLAP 厂商都在追着 Snowflake 的 2013 年设计思路走——当时就是基于 Snowflake 创始人之一的
博士论文
[67]
。
如今更重要的是用户体验（难以量化和收费）、与其他工具的兼容，以及 AI / LLM 的点睛之笔
。
不过这种竞争对用户来说是好事。狼多肉少，才能逼着技术进步、价格往下走。就像 Snowflake 现在把 Polaris 也捐给了
Apache
[68]
，这不就是多一分开源、多一些平价选择嘛。可别整成过去 Oracle 和 SalesForce 那种“两个土豪 CEO 互相喷口水”，大把烧钱然后用户也没啥实际好处。
DuckDB 缝合大赛开始！
就像做在线业务时，首选数据库是
PostgreSQL
一样，如今做分析时的 “默认之王” 就是 DuckDB
。以前大家可能还会说用 Pandas，但现在几乎一开口就是“DuckDB 走起”。这货特别轻便，所以很多人想把它塞进那些本身对 OLAP 支持不是特别好的数据库。今年，我们就看到四款把 DuckDB 集成到 Postgres 的扩展相继亮相。
第一枪是 2024 年 5 月，
Crunchy Data
[69]
宣布做了个
专有扩展
[70]
，把 Postgres 重定向到 DuckDB 来处理 OLAP 查询。随后他们又搞了个更厉害的版本，利用 DuckDB 的
空间扩展
[71]
来
加速 PostGIS 查询
[72]
。
2024 年 6 月，ParadeDB
发布
[73]
了一个开源扩展（
pg_analytics
[74]
），用 Postgres 的 FDW API 去调用 DuckDB。在此之前，他们用的是 DataFusion（
pg_lakehouse
[75]
），后来改用 DuckDB。
老冯评论：
我帮助 ParadeDB 打好了所有 Linux 上的二进制包，他们的创始人 Noel 曾经问我 PostgreSQL 分析引擎应该怎么做，我说：赶紧去缝 DuckDB 吧。他们是仅次于 duckdb_fdw 后第二个入阵的玩家。
8 月，官方版的 DuckDB-for-Postgres 出炉了（
pg_duckdb
[76]
），托管在
DuckDB Labs
[77]
的 GitHub 下，算是名正言顺的 DuckDB 官方插件。原本宣传说这是
MotherDuck
[78]
、
Hydra
[79]
、Microsoft 和
Neon
[80]
联合开发，结果后来据说 Microsoft 和 Neon 因为开发管理问题被“踢出去”了，就跟
阿拉伯王子
[81]
离开 NWA 一样。现在只剩 MotherDuck 和 Hydra 继续干。
11 月又来一个
pg_mooncake
[82]
插件（
博文
[83]
），这次是 Mooncake Labs 出品。它跟前面三个不太一样，是可以通过 Postgres 把数据写进 Iceberg 表里，还支持事务。
老冯评论：
国内开发者李红艳还有一个 DuckDB FDW 是另一个 Andy Pavlo 没有提到的 DuckDB 缝合玩家。起了个大早，占领了一个相当独特的生态位。(同样在 Pigsty 中可用，可惜与 pg_duckdb 不能同时安装)
Andy 的看法：
大多数分析查询其实访问的数据并不多。Fivetran 分析过 Snowflake 和 Redshift 的使用情况，发现
中位数查询只扫描 100 MB
[84]
数据。区区 100 MB，一台 DuckDB 完全够用了。
DuckDB 的便携和轻量，让它在 Postgres 社区倍受欢迎。虽说
ClickHouse
[85]
从 2016 年就有了，但以前想部署 ClickHouse 并没 DuckDB 那么简单（参考他们官方
回顾部署难度的文章
[86]
）。而且通过把 DuckDB 嵌到 Postgres 里，还能同时接驳 Iceberg、S3 等等，不用额外装其他插件。这让很多组织轻松获得高性能分析能力，而不用上昂贵的数据仓库。
至于 Postgres 的扩展机制，那真是强大。“可扩展”一直是 80 年代
Postgres 设计目标
[87]
之一，人家就是要支持新存储引擎、新数据类型等等。2006 年以后又引入了各种“钩子”API。我们在
CMU 的研究
[88]
里发现，Postgres 拥有数据库里最繁荣、最百花齐放的扩展生态。当然，也有副作用：扩展之间可能互相冲突，导致
奇奇怪怪的错误
[89]
。
之前那些给 Postgres 加列式存储的方案（比如 Citus、Timescale），只是解决了“存储格式”这一部分问题。可如果引擎本身还坚持
行式处理
[90]
，那终究还是不够。DuckDB 把列式存储和向量化执行流程都带到了用户面前。
话说回来，本来我想做个 “turducken（火鸡、鸭子、鸡三合一）”的梗，再配合 Postgres 的象征“大象”，可想想我还得保住饭碗，免得学校
找我麻烦
[91]
，还是算了。
老冯评论：
PG 生态的 DuckDB 缝合大赛，算是一件干脆就是我放火点燃的赛事。
年初的一篇《
PostgreSQL正在吞噬数据库世界
》 传遍整个 PG 社区，成功的将 OLAP DuckDB 缝合推动成为了一场如火如荼的竞争。
关于 DuckDB 缝合大赛的评论，请看拙作：
《
谁整合好DuckDB，谁赢得OLAP数据库世界
》。
我认为 PG OLAP 扩展生态很快会出现类似 PGVECTOR 的爆款扩展，就在以上几个选手中诞生。（目前我比较看好 pg_duckdb 与 pg_analytics）不管怎么样，这些扩展目前
全部
都在我的
