8 月 26 日，AWS 与 DuckLabs 签了最终收购协议，预计 9 月初完成交割。这是过去一周开源数据圈最重的一笔交易。DuckDB 这些年走得越远，"会不会被某家云厂买下" 的猜测就越多；现在靴子落地了。
但要先拎清楚一个关键区别：AWS 买的是 DuckLabs 这家公司，不是 DuckDB 这个开源项目。DuckDB、DuckLake、Quack 这些项目的 IP 和商标仍然在独立的 DuckDB Foundation 手里，代码继续以 MIT 协议分发。AWS 拿到的是 30 多人的核心开发团队，以及把这条技术线用进自己产品里的能力。
一、DuckLabs 是什么、这次到底买了什么
DuckLabs 是 2021 年从荷兰 CWI（数学与计算机科学国家研究所）孵化出来的商业公司。它的角色很单纯：给 DuckDB 的核心开发团队提供雇佣关系，通过商业支持合同获得收入。创始人 Hannes Mühleisen 和 Mark Raasveldt 这几年一边写数据库、一边做公司，团队没有接受过 VC，所有权一直在创始人和开发者手里。
这次交易之后，结构变成四层：
- DuckLabs 公司：归 AWS，预计纳入 AWS 团队
- 30 余人开发团队：留在阿姆斯特丹，由 Hannes 和 Mark 继续领导技术方向
- DuckDB / DuckLake / Quack 项目：继续在 DuckDB Foundation 治理下开发
- 核心 IP 和商标：仍然在基金会手里，MIT 许可证不变
这个安排对开源用户来说是最关心的——AWS 没法"收回"已发布的 MIT 代码。AWS 拿到的是两位创始人 + 核心开发者每天的工作时间、内部优先级，以及把这支团队长期绑定在自己产品路线图上的协作效率。
二、DuckDB 为什么值得 AWS 出手
DuckDB 不是一个"看上去不错"的小众数据库。它过去几年是 OLAP 引擎里跑得最猛的开源项目——每天下载量超过 100 万次，浏览器里能跑（WebAssembly）、嵌入式形态进入应用进程、Serverless 里能按查询启动。这条"嵌入到任何地方都能跑"的能力，正是 AWS 想要的执行入口。
AWS CTO Werner Vogels 在配套文章里给了一个判断："Architecture is a function of physics。" 单机的核心数、内存、I/O 和网络能力这些年涨了 50 倍量级（从 m1.xlarge 到 m8g.48xlarge），以前必须上集群才能干的活，现在一台机器就够。DuckDB 干的就是把高效的单机执行做成一个可以进入浏览器、应用、Lambda、EC2 的组件。
具体到 AWS 的产品线，DuckDB 的价值有这几层：
- S3 Tables：2025 年 3 月 DuckDB 已经支持通过
ATTACH直接查询 S3 上的 Iceberg 表。客户已经在这么用，AWS 顺势把执行入口收到自己手里 - Quack 服务端协议：今年 5 月发布的 DuckDB 客户端-服务端协议，浏览器里的 DuckDB-Wasm 可以直接连远端 DuckDB 实例。AWS 一旦做托管，这条路已经铺好
- DuckLake：把 Lakehouse 的元数据从一堆 Iceberg 文件挪回 SQL Catalog，恰好对上 AWS 的 S3 + RDS/Aurora 组合
换个角度说：Redshift 解决的是上一代"先把数据搬进数据仓库"的场景；DuckDB 解决的是"数据就在对象存储上，让查询引擎走过去"的场景。AWS 现在两条都想要。
三、对开发者和生态意味着什么
最直接的问题：MIT 承诺到底靠不靠谱？
法律层面靠谱。DuckDB Foundation 公开声明项目继续 MIT，IP 和商标由基金会持有。即使 AWS 后续改变产品策略，MIT 代码的 fork 权始终在社区手里。这一点上，对比一些"被收购后悄悄改许可证"的开源项目，DuckDB 的安排要干净得多。
但代码开源 ≠ 开发能力独立。30 多个人的核心团队全部成为 AWS 员工后，基金会的决策独立性会出现微妙变化。基金会目前董事会只有 Hannes、Mark 和 CWI 的 Peter Boncz 三人——前两位同时是 AWS 员工。DuckLabs 提到要建一个 stakeholder advisory board，让社区和关键利益相关方参与路线讨论。这是好事，但实际怎么运作要等交割之后看几个具体信号：advisory board 的成员与权限、非 AWS Maintainer 的数量、CI 和发布基础设施能不能由基金会独立运营。
对普通开发者来说，短期变化不大：
- 你的 Python notebook 里
import duckdb还是照常工作 pip install duckdb还是会装到 v1.5.0（v2.0 还在预览）- ATTACH S3 Tables 这条路只会越走越顺，不会被堵
中期要看两件事：
第一，MotherDuck 的处境。 MotherDuck 是目前商业托管 DuckDB 的主要玩家，DuckLabs 持有其部分股份。MotherDuck CEO Jordan Tigani 在交易当天的回应很坦率：欢迎竞争，会继续做企业支持。AWS 一旦发托管 DuckDB 服务，MotherDuck 的护城河会被部分侵蚀——但 MotherDuck 四年的服务运营经验不是 AWS 凭空能拿走的。
第二，AWS 之外的云会不会被"边缘化"。 这是更大的问题。S3 现在已经不只是 GET/PUT/LIST，还新加了 table bucket（管理 Iceberg 表）、vector bucket（向量索引与相似度查询）。如果 AWS 每次先发新的 bucket 类型，DuckDB 第一时间支持，Cloudflare R2、GCS 这些 S3-compatible 的对手就要排队适配。默认值会先在 AWS 生态里写定。
四、最后
这笔交易最值得记住的不是"DuckDB 被收购了"，而是 AWS 用一笔不算大的钱（具体金额没披露），把未来分析栈里"默认值"这个位置的发言权买下来了。DuckDB 不会变成 Redshift 那种集中式数仓，它会继续在浏览器、应用进程、Lambda、EC2 各种地方跑；AWS 不需要控制它跑在哪里，只要持久数据还留在 S3、查询入口的默认实现首选 DuckDB，AWS 在下一轮分析栈里的话语权就稳了。
对使用者来说，这是一场划算的赌注：MIT 给你的 fork 权没被拿走，AWS 的资源投进来之后 DuckDB 的工程交付能力还会上一个台阶。只要基金会治理别走样，未来几年 DuckDB 仍然是单机 OLAP 的最佳选择。
评论交流
发表评论