DuckCon #7 到底谈了些啥

两天前，阿姆斯特丹皇家热带研究所里坐了满满一屋子人。

他们是来参加 DuckCon #7 的——DuckDB 的第七届开发者大会。门口堆着马克杯和贴纸，吧台后面备好了啤酒，开场前半小时签到队伍排到了门口。一个做嵌入式数据库的会，热闹得像前端框架发布会。

但真正让我停下来的是议程上的第一个名字：Merck KGaA。

这家德国制药巨头，在会上讲了一件事：他们把 PySpark 迁移到了 DuckDB。不是"尝试"，不是"PoC"——是实打实的生产线迁移。

一个嵌入式数据库，开始吃掉 Spark 的工作负载。而这只是整场大会的开场。

● ● ●

默克停了 Spark，代码几乎没改

如果你在大厂做数据，PySpark 可能是你最贵的依赖之一。不算人力，光是 Spark 集群的运维成本就够买一个中型团队的年薪。

默克的数据团队用了一个叫 SQLFrame 的开源工具。它做了什么？实现了 PySpark 的 DataFrame API，但底层跑的是 DuckDB。 基于 SQLGlot 做 SQL 方言翻译，你的 spark.sql()、df.groupBy()、df.join() 都不需要改——只是底层从 Spark 换成了 DuckDB。

这意味着什么？

你在笔记本上写的那段 PySpark 代码，原来要扔到集群上跑 20 分钟，现在单机 3 秒，结果一样。

默克不是第一家。Palantir Foundry 已经官方支持了同样的迁移路径。DuckDB 自己的文档里也写了 Spark API 兼容层。

Spark 的护城河原来不深——很多时候，我们只是被 API 绑住了，不是被算力需求绑住了。

● ● ●

Spotify 把收听历史变成了 AI 能查的 SQL

全场最让我兴奋的演讲来自 Spotify 的 Kian Mehrabani。

Spotify 有海量的用户收听历史数据——谁听了什么、什么时候听、跳过了多少秒、在哪个播放列表里循环了哪首歌。这些数据散落在事件流和日志系统里，传统上分析师要写复杂的 Pipeline 才能回答一个简单问题。

Spotify 的做法是：在原始事件数据上建一层 SQL 抽象，然后用 DuckDB 做查询引擎。

但这层的真正杀手锏不在分析师——在 AI Agent。

他们把这个 SQL 层暴露给了内部的 AI Agent。Agent 不用理解事件流、不用看日志格式——它直接写 SQL："找出过去30天早上8-10点听爵士乐的用户，其中哪些也听过古典？" DuckDB 亚秒级返回结果，Agent 继续推理。

这是"Agentic Data Access"的实际落地：不是让 Agent 写代码操作数据，而是把数据本身变成 Agent 能理解的语言。

如果 Spotify 在做这件事，可以想象接下来会发生什么：Salesforce、Stripe、Shopify 的数据都会长出 SQL 层，然后 Agent 会开始直接"跟数据对话"。

● ● ●

MariaDB 让海狮学会了鸭叫

Roman Nozdrin 来自 MariaDB 公司。他上台时我还没意识到这个 talk 有多硬。

MariaDB 做了一个插件：DuckDB 存储引擎。

怎么用？一行 SQL：

CREATE TABLE sales (
  id BIGINT PRIMARY KEY,
  product VARCHAR(64),
  amount DECIMAL(12,2),
  sold_at TIMESTAMP
) ENGINE=DuckDB;

然后正常查询就行——WHERE、JOIN、GROUP BY 全部下推到 DuckDB 的向量化引擎。更狠的是，你可以跨引擎 JOIN：InnoDB 的事务表和 DuckDB 的分析表在同一条 SQL 里关联，不用 ETL，不用 Pipeline，不用"先把数据导出来"。

性能？TPC-H SF10，22 条查询，一台笔记本，总耗时 4.3 秒。

这个演讲的标题叫 "When the sea lion learns to quack"——海狮是 MariaDB 的吉祥物，Quack 是 DuckDB 的远程协议。翻译成人话：传统关系型数据库，开始把分析引擎当插件用了。

● ● ●

几个让我记住的 Lightning Talk

闪电演讲每场只有 6 分钟，但密度极高：

Toyota Gazoo Racing 的 Milla Henriksson 分享了他们用 DuckDB 做拉力赛遥测分析。赛车每秒产生几百个传感器读数，工程师需要在比赛现场、用笔记本电脑、实时分析——DuckDB 是他们选的引擎。

Floyd Berndsen 做了一个让我想立刻复现的项目：在 Hetzner 上搭了一个完整的 DuckLake 数据湖仓——PostgreSQL 做元数据、S3 存 Parquet、DuckDB 做查询引擎——全栈月费不到 €15。他还开源了权限管理工具 ducklake-guard。

Barry Smart 来自 endjin。他用一台笔记本和 DuckDB，审计了英国 20 年的风力发电政策数据。没有集群，没有云端数仓，就一台电脑。

Thomas Visser 来自 Hartwig Medical Foundation。他们用 DuckDB 做癌症基因组学研究——处理数百 GB 的基因突变数据，在本地完成分析。以前这种事需要专门的生物信息学集群。

Marco Slot 来自 Snowflake。没错，Snowflake 的人在 DuckDB 的会上分享 pg_lake——一个 PostgreSQL 扩展，用 DuckDB 引擎直接查询 Iceberg 和 Parquet 文件。连竞争对手都在用 DuckDB 做引擎。

● ● ●

这只鸭子已经不是"嵌入式数据库"了

回头看 DuckDB 的发展轨迹：

三年前它是一个"SQLite for analytics"。现在它是一整个数据栈的替代品。

Merck 用它替代了 Spark。Spotify 用它给 AI Agent 提供数据接口。MariaDB 把它嵌进了自己的引擎。Snowflake 用它查询 Iceberg。有人用它在 €15/月的虚拟主机上搭了完整的湖仓。

这不是一个"好用的嵌入式数据库"的故事。这是一个"我们可能不需要那么多分布式系统"的故事。

● ● ●

什么时候你不需要 DuckDB

当然，DuckDB 不是万能的。

如果你真的有 PB 级数据需要实时并发查询——几百个用户同时跑复杂聚合——你还是需要 Snowflake、BigQuery 或者 Databricks。DuckDB 的 Quack 协议还在 Beta，多节点架构还没到生产级。

如果你的数据已经在 Snowflake 里跑得很好，迁移没有意义——不是说 DuckDB 不好，是迁移的成本不值得。

但如果你正在为一个新项目选型，或者现有的 Spark 集群运维成本让你头疼，或者你想让 AI Agent 直接查你的数据——DuckDB 可能是你今天最该认真评估的工具。

这也是为什么 DuckCon #7 的票卖得这么快。

不是因为鸭子吉祥物可爱。是因为越来越多的人开始怀疑一件事：过去十年我们默认的"做分析就要建集群"，可能从一开始就不是唯一的选择。