AWS 收购 DuckDB：鸭子飞进亚马逊雨林
微信原文 | 2026 年 8 月 26 日
8 月 26 日，亚马逊官宣：AWS 已与 DuckDB 背后的公司 DuckLabs 签署最终收购协议，预计 9 月初交割，金额未披露。团队留在阿姆斯特丹，DuckDB、DuckLake、Quack 三个项目继续以 MIT 协议开源，挂在独立的 DuckDB 基金会名下。
公告里有一句话写得很讲究：「我们并不是在收购 DuckDB 开源项目」。这话不假，但这笔交易的机关也全在这里：项目留给基金会，人归我。
先交代一下背景。DuckLabs 是阿姆斯特丹 CWI（荷兰数学与计算机科学研究中心）的学术 spin-off，Hannes Mühleisen 和 Mark Raasveldt 两位博士 2018 年在 CWI 动手写 DuckDB，之后拉起了公司。
三十来号人，零 VC 融资，股东就是创始人和员工自己，靠支持合同和开发合同养活自己，典型的欧洲小作坊。就是这么一个小作坊，做出了如今每天被下载三百多万次的分析数据库，把一票融了几亿美金的同行按在地上摩擦。现在，它被 AWS 整锅端走了。
时间点
这笔收购最有意思的地方在时间线上。8 月 17 日，DuckDB 放出 2.0 前瞻：全新的客户端协议 Quack 登场，外加多进程并发读写。九天之后，8 月 26 日，AWS 官宣收购。
这九天透露出来的信息，比公告本身还多。DuckDB 此前一直是个进程内的嵌入式库，好用，但没法直接拿去卖。有了客户端协议之后，它就不再是一个库，而是一台可以被托管、被计费、被塞进云控制台的服务器。
嵌入式的 DuckDB 是开发者的工具，带协议的 DuckDB 是云厂商的印钞机。AWS 偏偏在鸭子长出翅膀这一刻出手，说是巧合，我反正不信。
Hannes 自己在表态里也把牌摊开了：AWS 带来的规模和触达，能让更多用户用上这项技术，包括那些最终依赖 Duck Stack、但不需要自己运维数据库的人。
最后半句就是产品预告。我在这里立一个可以被打脸的 flag：今年 12 月的 re:Invent 上，大概率会出现基于 DuckDB 的托管服务，形态或许是 S3 的原生查询引擎，或许干脆就叫 Amazon DuckDB 或者 Amazon Quack。
出手的不是 Redshift，是 S3
另一个容易被略过的细节是，替 AWS 出面站台的人是 Andy Warfield：AWS 副总裁、Distinguished Engineer，S3 的掌门人。他说双方已经密切合作了两年，联手把 DuckDB 塞进了 S3 Tables 和 SageMaker Lakehouse，还夸 DuckDB 被 S3 客户广泛使用、深受喜爱。
买鸭子的不是 Redshift 团队，是 S3 团队，这个差别很要紧。因为 Amazon 自己的数据仓库产品 Redshift 和 Athena 都实在太拉胯了。AWS 官方的措辞其实已经透露方向：收购 DuckLabs 是为了让 AWS analytics “faster, simpler, and more cost-effective”，比较对象是谁不言而喻。
这几年整个云上数据基础设施都在往对象存储上搬家，各路「XXX over S3」层出不穷。文件系统与数据库这对冤家的恩怨，我在《DB vs FS：相爱相杀 50 年》里聊过。S3 自己也没闲着，先把 Iceberg catalog 直接做进存储服务（S3 Tables），现在又把这颗星球上最擅长读对象存储的查询引擎团队整个买下。对象存储正在长出计算能力，而查询引擎正在沦为存储的配件。
放进牌局里看就更清楚了：Databricks 手握 Delta 与 Unity Catalog，Snowflake 有 Polaris，如今 AWS 凑齐了 S3 Tables + DuckDB + DuckLake。湖仓三国杀，齐活了。
买人不买项目
镜头拉远一点，这笔交易只是一个更大序列里的最新一单。
MySQL 当年连人带项目十亿美金卖给 Sun，再被 Oracle 一锅端，那是旧模式，代价是社区至今心有余悸。Citus 2019 年卖给微软，算是中间态。前年 Rockset 卖给 OpenAI，去年 Neon 十亿美金卖给 Databricks、Crunchy Data 卖给 Snowflake。包括最近 pg_mooncake / electricSQL 卖身——数据库引擎的人才，正在被平台公司成建制地收编。
AWS 这次的姿势是其中最精致的一种。还记得当年 Elastic 换协议，指着 AWS 的鼻子骂「strip mining」吗？AWS 被迫 fork 出 OpenSearch，后来干脆捐给了 Linux 基金会。骂挨了，乖也学了。所以这回的话术无懈可击：项目不碰，留在基金会，章程保证 MIT 永续，我们只是雇佣了全部核心开发者而已。既堵住了「吞并开源」的悠悠之口，又实实在在攥住了路线图。上一个十年，云厂商白嫖开源；这一个十年，云厂商直接把上游买成自己的员工。
平心而论，站在 DuckLabs 的角度，这个归宿不丢人，甚至可以说体面。他们早在 2022 年就坦承过，光靠咨询与支持合同的模式撑不起规模。这次官宣配套的承诺也确实是加分项：扩大基金会的角色，设立商业用户顾问委员会，开放扩展签名让第三方组织也能发布扩展，以及用他们自己的话说，消除把免费用户转化为付费支持客户的商业压力。
说白了，以前得靠卖支持恰饭，现在有亚马逊发工资，反而可以把生态放得更开。这跟 SQLite 靠财团供养的模式神似，区别只在于 SQLite 的金主是一个财团，而 DuckDB 的金主从今往后只有一家。而单一金主，恰恰是真正的问题所在。
一个属于世界，一个属于亚马逊
我此前讲过一个判断：数据世界正在收敛出几个默认答案，数据库的默认答案是 PostgreSQL，对象存储的默认答案是 S3，而分析的默认答案会是 DuckDB。这次收购等于 AWS 用真金白银替我确认了第三条。
可惜 DuckDB 本来可以算个「不由单一实体说了算」的案例。从今天起，这个对称性破了一半。DuckDB 项目确实还在基金会，MIT 确实永续，但核心开发者几乎全员领同一家公司的工资，而这家公司是全世界最大的云。
PostgreSQL 的强健，恰恰在于核心贡献者的雇主是散的：EDB、微软、AWS、富士通、NTT、Crunchy Data……谁也不占多数，谁也别想一言堂，哪家想夹带私货，社区里有的是人跟你拍桌子。DuckDB 从今天起暂时失去了这个性质，基金会还在，但基金会里坐着的人，胸牌都印着同一个 logo。
当然，天也没塌。MIT 协议摆在那里，真到了变卦那天，社区手里还有终极武器，那就是 fork。Redis 前脚改协议，Valkey 后脚立地成佛，殷鉴不远。但结构性风险从零变成了非零，这笔账，用 DuckDB 的人心里要有数。
三个默认答案如今的格局是：PG 属于世界，S3 属于亚马逊，DuckDB 悬在半空，基本上也要属于 Amazon。
最坐立难安的是 MotherDuck
这笔交易里还有一只当事鸭，处境瞬间变得微妙，那就是 MotherDuck。
给不熟的读者补个背景：MotherDuck 是拿了约一亿美金 VC 的创业公司，创始人 Jordan Tigani 是前 BigQuery 老兵，商业模式就是「云上的 DuckDB」，基础设施跑在 AWS 上。DuckDB 官方 FAQ 里白纸黑字写着两层关系：MotherDuck 与 DuckLabs 签有开发服务合同，DuckLabs 持有 MotherDuck 的股份。
于是 AWS 买下 DuckLabs 之后，AWS 间接成了 MotherDuck 的股东，MotherDuck 核心引擎的外包开发方变成了 AWS 的全资子公司，而 MotherDuck 卖的东西，恰好是 AWS 接下来最可能亲自下场卖的东西。甲方、乙方、股东、房东，如今全是一家人。
更巧的是，就在官宣前一两天，MotherDuck 刚刚收购了 Tower，一家支撑其数据管道功能的基础设施小厂，用来补自己的工程班底。
鸭子范式：元数据进 PG，数据放 S3
聊完资本，说回技术。AWS 到底看上了什么？我认为答案有两层。
第一层是范式。DuckLake 的架构说穿了就一句话：元数据进数据库，用 PostgreSQL；数据进对象存储，落成 S3 上的 Parquet；计算则交给无状态、随起随灭的 DuckDB。它不只是又一个表格式，而是把「Iceberg + 各家 Catalog」整个栈端掉的路数。元数据本来就是关系型的，塞回关系型数据库里天经地义，何必用一堆 JSON 文件在对象存储上模拟一个蹩脚的数据库？
进行这项尝试的，还有刚刚被 Snowflake 收购的 Crunchy Data，他们搞的 pg_lake 也是几乎一样的思路，只不过选择在 PG 中做这件事，继承 PG 的权限模型，而不是像 DuckLake 一样让你自己去 DIY。
主数据放对象存储、元数据放 PG，这个套路正在成为新一代数据系统的标准姿势。不用看远，我朋友蒋老板最近攒的四个数据库，图数据库也好、消息队列也好，无一例外全是这个架构。这不是巧合，这是范式。而如今范式的原作者进了 AWS，范式本身只会加速成为行业标准。
第二层是时代。每天三百多万次下载，你以为背后是三百万个数据分析师？相当一部分是 AI agent。零配置、单二进制、进程内、即用即抛，DuckDB 是 agent 干数据活时的本能选择，DeepSeek 的 smallpond 拿它配 3FS 攒分布式分析，就是现成的例子。AWS 买的不只是一个 OLAP 引擎，买的是 agent 时代数据处理的默认心智。
尾声
几年前我把 DuckDB 整合进 Pigsty 的时候，它还只是极客圈子里的小众玩具。我很早之前就觉得，除了 PostgreSQL 之外最有前景的数据库就是 DuckDB，话音未落，AWS 用支票投了同一票。
接下来的剧本不难猜：AWS 会把托管版 Duck Stack 端上货架，广告词 Hannes 已经替它写好了——让用户依赖 Duck Stack，而不必自己运维数据库。
这个故事的镜像，是自建版的 Duck Stack：PostgreSQL 管元数据，MinIO / Silo / RustFS 之类的对象存储放数据，DuckDB 跑计算，全套开源，一分钱订阅费不用交给贝索斯。巧了，这三样东西，Pigsty 里一样不缺。
一行命令，你就可以在自己的 Linux 服务器上，拥有生产级的高可用 PostgreSQL 集群，生产级的 Silo / MinIO（下个版本加入 RustFS 支持）对象存储集群，以及开箱即用的 DuckDB 与 PG DuckDB 全家桶扩展。
市场教育，亚马逊已经替所有人做完了，剩下的是一道选择题：数据的家底，是托付给雨林，还是攥在自己手里。
三十年，数据世界才收敛出三个默认答案。而让其中一个易主，只需要一份签好字的协议。愿鸭子在雨林里飞得高，也愿它落地的时候，还认得基金会的门。
参考链接