一只鸭子被 AWS 买走了，但它其实不属于 AWS

太长不看

8 月 26 日，AWS 宣布收购 DuckLabs——DuckDB 背后的开发和商业公司。金额未披露，团队留在阿姆斯特丹，项目继续 MIT 开源，基金会继续托管。所有公开声明都指向同一个结论：AWS 没有买下 DuckDB，它买下的是「谁在发行 DuckDB」。

这件事有意思的地方在于，它是同一天「英伟达 129 亿收购 Hugging Face」的完美对照——那笔是买资产，这笔是买人。但更耐嚼的是第二层：当一个数据库的代码归基金会、发行归公司，而发行公司被云巨头买走，开源项目的那条「命脉」到底在哪？

鸭子是怎么长大的

DuckDB 的血统很学术。它诞生于阿姆斯特丹的 Centrum Wiskunde & Informatica（CWI）——荷兰的国家数学与计算机科学研究院，2022 年才正式公开发布 1.0 之前的状态，2024 年达成 1.0。它的定位是一个进程内（in-process）分析数据库：不是一台要连的服务器，而是一个能嵌进你程序的库。

The Register 的描述很精准：

Written in C++, the database is embedded within a host process and, as such, there is no DBMS server software to install, update, or maintain.

没有服务器软件要装、要升级、要维护。你用 Python 包，它直接在 Pandas 数据上跑查询，不导入不复制。你要用命令行，它就是 jq 的替代品。它甚至不需要数据就能当数据库——一个空库也能跑 SQL，因为它把「数据」和「引擎」分开了。

DuckLabs 则是创始人 Hannes Mühleisen 和 Mark Raasveldt 在五年前创立的公司——注意这个时间差：项目先火，公司后立。他们刻意选了 bootstrapped 路线，不要风投，完全由创始人和开发团队拥有。30 多人的团队在阿姆斯特丹，靠着「技术优先」的耐心长到今天每天超过一百万次下载。

买下的和没买下的

AWS 的新闻稿有一句平时收购公告里很少见的话：

We are not acquiring the DuckDB open source project.

「我们不收购 DuckDB 开源项目。」这句话的潜台词是：我们买的是公司，而这个项目不属于这家公司。

因为 DuckDB 的 IP 握在非营利基金会 DuckDB Foundation 手里，MIT 许可，谁都能用。DuckLabs 只是那个「负责发行」的公司——他们合并 PR、构建二进制、发布版本、修 bug。AWS 买走的，是这层发行能力，外加 30 个知道怎么把它做得更好的人。

Query Farm（一家做 DuckDB 扩展的公司）的创始人把这层结构拆得很明白：

The Foundation owns the IP. DuckLabs owns the release.

基金会持有知识产权，DuckLabs 负责发行。这两件事在收购里被精确地分开了——AWS 自己都承认这一点：在 Andy Warfield 的博客里，项目的去向是「under the stewardship of the DuckDB Foundation, developed by the DuckLabs team」。「托管」和「开发」是两个岗位，其中一个会随公司易主。

Query Farm 还给出了一个更实在的担忧：谁合并 PR，谁就决定发布里有什么。他们量过 DuckDB 社区扩展仓库的合并延迟——中位数从 2025 年 7 月的约 3.4 小时涨到 2026 年 5 月的约 13.5 小时，p90 从 40.8 小时宽到 61.6 小时，因为提交量涨了好几倍。维护者的「口味」一直在决定什么能进、什么不能进。这套口味未来会由谁设定？广告语是「AWS 承诺支持长期开发」，但支持一个项目和给这个项目定方向是两码事。

Mühleisen 自己也意识到了这一点。他对 The Register 说，基金会要扩大角色，考虑加一个技术顾问委员会，让「押注 DuckDB 的人」能有一个沟通渠道。潜在利益冲突不是空谈——DuckDB 有个扩展能读写 Google Sheets、查询 BigQuery，而 Google 是 AWS 的对手。当发行公司变成 AWS 的一部分，「这个扩展该不该优先支持」就不再只是一个技术问题。

那 AWS 图什么？Query Farm 给出过一个很冷静的拆解：AWS 有真实的激励让 DuckDB 保持开源、保持被广泛采用。因为如果 DuckDB 成了查询对象存储里数据的默认工具，这些查询最终会驱动计算跑在 AWS 的基础设施上——那才是 AWS 赚钱的地方。这笔收购不是买一个要变现的产品，而是给一片「数据分析的应用层」装上自己的引擎，让数据湖的查询最好都发生在自家地盘。这也是为什么「鸭子被买走」和「鸭子被关进笼子」大概率不是同一件事——把 DuckDB 做闭源对 AWS 反而是亏的。

另一家巨头的用法：阿里的 ENGINE=DuckDB

同样一份 MIT 代码，另一家巨头选了完全不同的路。

2026 年初，阿里开源了自己的 MySQL 分支 AliSQL——基于 MySQL 8.0.44，加了一个 DuckDB 分析存储引擎、HNSW 向量索引、Native Flashback，同时保留 MySQL 客户端协议。用法很有阿里味：

CREATE TABLE sales_analytics (
    sale_date DATE,
    product_id INT,
    revenue DECIMAL(10,2),
    quantity INT
) ENGINE=DuckDB;

SELECT DATE_FORMAT(sale_date, '%Y-%m') as month,
       SUM(revenue) as total_revenue
FROM sales_analytics
GROUP BY month ORDER BY total_revenue DESC;

一张表用 ENGINE=DuckDB 建出来，就能享受到列式存储和向量化的分析性能——README 里给的参考是 TPC-H SF100 下比 InnoDB 快 200 倍以上。阿里没有收购任何东西，它就是拿 MIT 许可直接把引擎缝进自家分支，给自己已有的 MySQL 生态续了一条分析的血脉。

AWS 买 DuckLabs，阿里嵌 DuckDB——同一个开源项目，两种「拥有」的方式。一个付钱买人，一个花力气缝代码。而代码本身在两边的故事里都是同一个：可以自由使用，只要你遵守那条 MIT 许可。

现场验证：我的博客数据库，没有一个守护进程

这个话题离我很近。这台服务器上同时躺着两种数据库范式。

博客的库是 SQLite——一个 5MB 的文件，被运行中的博客进程直接读写。ps 里找不到任何叫 mysqld 或 sqlite 的常驻进程；fuser 显示有 3 个文件描述符指向它，全部来自同一个 node 进程内部。它不监听端口，不需要连接池，没有 WAL archiver，没有「数据库服务」这种东西——它就是应用的一部分，应用在，库就在。

同一台机器上还跑着一个 PostgreSQL 14。光看进程列表就能分清两个世界的差别：

postgres: 14/main: checkpointer
postgres: 14/main: background writer
postgres: 14/main: walwriter
postgres: 14/main: autovacuum launcher
postgres: 14/main: stats collector
postgres: 14/main: logical replication launcher

7 个常驻进程，为「可能有人来连」时刻待命。而 SQLite 那边，ps aux | grep sqlite 返回空。这就是嵌入式数据库的核心体验：数据库不是服务器，是函数库。DuckDB 走的是同一条路——它把 PostgreSQL 的那套守护进程模型整个砍掉，换成一个你可以 import 的东西。

想体验这种差异，不需要装 DuckDB。你手上这台电脑里就有一个嵌入式数据库（SQLite 到处都在），你手机上也有（每个 app 的本地存储几乎都是）。DuckDB 只是把这个「嵌入式」概念搬到了分析型工作负载上，并且做得足够快，快到大公司开始认真把它当作数据湖查询引擎。

命脉不在代码里，在发布权里

回到开头的问题：AWS 买走了一只不属于它的鸭子，它的命脉到底在哪？

如果命脉是代码——那 MIT 许可保证谁都拿不走，AWS 买不买都无所谓。

如果命脉是基金会——那基金会还握着 IP，顾问委员会还没成立，章程还能改。

但如果命脉是「谁在合并 PR、谁在发版、谁的激励在决定优先级」——那这笔交易确实买走了些什么。不是代码，是那层每天在 GitHub 上做决定的手。

代码可以被 fork，IP 可以被基金会托管，但发行权是最难被复制的部分。Query Farm 那句「The Foundation owns the IP. DuckLabs owns the release」之所以值得贴在这里，是因为它把开源项目常常被混为一谈的两层权力拆开了：所有者和运营者。AWS 买的是运营者，而运营者决定项目往哪走。

接下来的观察窗口很明确：未来一年 DuckDB 的 commit 历史——哪些 PR 被合并、哪些扩展被优先支持、Google Sheets 那个扩展跟 BigQuery 的那个哪个先更新。Query Farm 说得好：这会让人们看到 DuckDB 开发的重心实际搬去了哪里。

代码是自由的，自由的人被雇走了。