AWS收购DuckDB Labs：代码没有易主，路线之争才刚开始

很多标题把这笔交易写成“AWS收购DuckDB”。严格说，不准确。

AWS买下的是DuckDB Labs，也就是核心开发团队所在的商业公司。DuckDB开源项目仍由独立的DuckDB Foundation承担治理职责，现有代码继续使用MIT许可证。交易价格和具体整合路线没有公开。

所以，今天醒来打开DuckDB的开发者，不需要迁移，也不会突然收到AWS账单。

真正发生变化的，是写代码的人去了哪里，以及他们以后优先解决谁的问题。

AWS买下公司，基金会留在原地

DuckDB是一款嵌入式分析数据库。它不要求团队先部署一套数据库服务，装进Python、R或应用程序里，就能直接查询CSV、Parquet等数据。

这种设计让它常被称为“分析领域的SQLite”。两者并不完全一样，但思路接近：降低部署成本，让数据库能力贴近本地程序。

这笔交易目前能确认的边界很清楚：

• DuckDB Labs进入AWS体系，核心团队获得更大的工程和资金支持。
• DuckDB Foundation继续负责开源项目治理。
• 已发布的MIT许可版本不会因为收购而被收回。
• 交易金额、团队考核方式、AWS产品整合计划尚未披露。
• MotherDuck是独立公司，不在已披露的收购范围内。

“代码即法律。”Lessig这句话放在这里很合适。MIT许可证决定了AWS不能阻止其他公司继续使用、修改和销售现有DuckDB代码。

但许可证只管代码权利，不管人的时间。

如果主要维护者都受雇于同一家公司，那么新功能先做什么、性能优化偏向哪种存储、发布节奏如何安排，仍可能受到雇主需求影响。基金会的法律独立很重要，却不能自动消除贡献者集中的现实。

AWS看中的，是S3旁边的计算能力

AWS已经有Redshift、Athena、Glue和S3。它不缺数据库产品，也不缺查询入口。

DuckDB补上的，是一种更轻、更靠近文件和应用的执行方式。开发者可以直接查询S3里的Parquet文件，不必先把数据全部搬进传统数据仓库。对数据科学、日志分析和本地开发，这种体验很有吸引力。

AWS收购DuckDB Labs，更像是在争夺下一代数据工具的默认执行层。

如果DuckDB与S3、IAM、Glue Catalog等服务结合得更紧，AWS可以让开发者更自然地留在自己的存储和权限体系里。查询引擎本身免费，数据、权限和计算消费仍发生在云上。

这套生意并不新鲜。云厂商常用开源工具降低入口成本，再靠托管服务和基础设施收费。“天下熙熙，皆为利来”，开源与商业从来不是对立面，争议只在收益和控制权如何分配。

过去几次冲突，给出了不同结局：

DuckDB目前的结构比当年的MySQL更有缓冲，也不同于Elastic直接调整许可证的路线。基金会是一道制度防线。

只是防线是否有效，要看具体权力：谁能决定发布，谁控制商标，董事会如何组成，非AWS贡献者能否进入核心维护层。基金会的名字本身不能回答这些问题。

MotherDuck承受的不是断供，而是路线压力

处境最微妙的是MotherDuck。

MotherDuck把DuckDB做成云数据平台，卖点正是本地DuckDB与云端计算协同。它不会因为这次收购失去MIT代码，也可以继续开发自己的服务。

压力来自更现实的地方。

如果DuckDB的新能力优先适配S3和AWS产品，MotherDuck可能需要投入更多工程资源，确保自己的云端服务保持差异。若核心维护者都进入AWS，MotherDuck获得路线信息和技术支持的方式也可能改变。

这不等于双方必然翻脸。AWS也有理由维护DuckDB的跨平台形象。开源项目一旦被社区视为某家云厂商的附属组件，其他云平台和独立开发者会减少投入，AWS买到的影响力反而会缩水。

收得太紧，项目会失去价值；放得太松，商业协同又难以兑现。这才是交易后的真实约束。

对开发者来说，现在没有暂停采用DuckDB的理由。更实际的做法是锁定版本、保留回归测试，并观察未来几个版本的发布记录和贡献者分布。不要因为一笔收购，制造一次没有收益的迁移。

企业采购方要多问几句。如果业务依赖MotherDuck或其他DuckDB云服务，应确认支持合同、版本兼容承诺和数据导出路径。新项目也别把AWS专属集成写死在核心架构里，除非团队本来就决定长期使用AWS。

判断这笔收购是否伤害开源，不必猜公关稿背后的心思。看三件具体的事就够了：基金会治理有没有变化，非AWS贡献是否继续增长，新功能是否仍对多云和本地场景一视同仁。

代码仓库还在公开，只能说明门没有锁。

至于路往哪里修，要看接下来谁拿着图纸。