一句话钩子：42,674★ · MIT · 日下载 300 万 + —— 2026-08-26，AWS 宣布把 DuckDB 背后的公司 DuckLabs 收入麾下；但 DuckDB、DuckLake、Quack 三个项目的版权与商标留在了荷兰的非营利 DuckDB 基金会。55 天后，DuckDB 2.0 发布：给这个「坚决不要 server」的数据库加上了网络互联。这可能是今年开源治理最重要的一堂公开课：license 从来不是控制点，发薪日才是。
写在前面：三个月前埋的伏笔，现在可以复盘了
上一版 DuckDB 调研 发布时，它还是「嵌入式 OLAP 神兽」的故事；Rill 那篇 里，DuckDB 是别人引擎底下的内核。三个月后的今天，故事的主线变了：AWS 买走了造 DuckDB 的公司，而 DuckDB 本身留在了原地。
这件事值得单独写一篇，不是因为它大——收购金额都没披露——而是因为它把一个老问题演成了教科书案例：当一家云巨头雇走一个开源项目的全部核心维护者时，开源协议到底保护了什么？ DuckLabs 官方公告（8/26，本篇一手源）与 10/21 的 DuckDB 2.0 公告连起来看，答案比想象中清晰。
一、交易本身：什么被买走，什么留下
| 维度 | 内容（来源：ducklabs.com 官方公告 8/26） |
|---|---|
| 收购方 / 标的 | AWS 收购 DuckLabs B.V.（阿姆斯特丹，DuckDB 开发团队，30+ 工程师） |
| 时间线 | 8/26 宣布，「expected early September」生效；二手时间线（墨天轮援引 AWS 官方）称 8/31 交割、9/1 团队入职——以官方「9 月初」为准 |
| 留在基金会 | DuckDB、DuckLake、Quack 及生态组件：版权与商标归非营利 DuckDB Foundation，继续 MIT |
| 团队去向 | 全员留阿姆斯特丹，继续开发 DuckDB 生态；两位创始人继续领导技术方向 |
| AWS 站台人 | Andy Warfield（VP & Distinguished Engineer）：「与 Mark、Hannes 和团队紧密合作约两年」 |
| 体量口径 | 日下载 300 万 +（官方公告口径；此前二手报道曾写 100 万 / 日，以官方为准） |
Warfield 那句「合作约两年」值得划重点：这不是突发收购，而是从 S3 Tables / SageMaker Lakehouse 集成开始的长期协作的收编。AWS 买的不是代码——MIT 的代码谁都能拿——买的是 发薪日：几乎全部全职维护者的雇主变成了 AWS。
二、为什么「留在基金会」比听起来重要
先说清楚结构：DuckLabs（公司）从头到尾不拥有 DuckDB 的知识产权——版权和商标在荷兰非营利 DuckDB Foundation 手里，章程锁定 MIT。所以这笔交易从法律上就 买不走项目，只能买走人。
那基金会守护了什么？三样：
- 再许可权。代码永远不会变成非开源（章程约束），Databricks/Snowflake/Google 可以放心继续基于它造产品，不必担心哪天被改写成 AGPL 或 SSPL。
- 商标。「DuckDB」这个名字不能被云厂私有化成商业产品名。
- 中立的法壳。未来如果 DuckLabs 战略转向（比如全力服务 AWS），社区可以依托基金会 fork 续命。
但基金会 守护不了 的，恰恰是项目前进的方向：
- 维护者的注意力。接下来几年，性能优先优化 S3 还是 Azure Blob？扩展签名分发管道为谁的云服务开快车道？LTS 版本给谁的支持窗口更长？这些决策由拿 AWS 工资的人做出。
- 发布节奏与分发管道。谁运维 extension 的构建与签名管道，谁就决定普通用户
INSTALL能装到什么。 - DuckLake 的演进。这个湖仓格式还年轻，它的未来几乎等于团队的未来。
一句话：基金会保住了「永远不会变坏」，保不住「会往哪里走」。 这正是「license 不是控制点，发薪日才是」的完整含义。对照今年数据基建领域的其他并购（Deepgram 收 Pipecat 母公司等），DuckDB 是「保护结构」做得最好的案例——但保护的边界也就到那里。
三、DuckDB 2.0：他们一直要 server，那就给个选项
10/21 的 DuckDB 2.0 公告（第二份一手源）是这个复盘里最有趣的部分。Mühleisen 的原话几乎是自嘲：
「我们设计 DuckDB 就是让人不用跑数据库服务器就能分析数据。然后他们不断向我们要 server。我们决定这不是抛弃现有路线的理由，而是给人们多一个选项的理由。」
2.0 的关键变化，每一条都是对「嵌入式哲学」的扩容而非背叛：
- Quack 协议转正：DuckDB 实例之间可以走网络通信（5 月预览，2.0 转正）；
- CONNECT 语句：客户端把查询定向到远端共享实例、拿回结果——「应用内嵌」与「共享实例」从此是同一个产品的两种模式；
- 异步 I/O：远端对象存储操作加速；
- 可扩展 SQL parser + 扩展 C API + 触发器 + VARIANT：向「真数据库」的完备性补课；
- CLI Agent Mode：给 AI coding agent 用的命令行模式——数据工具第一次把「让 agent 用」列为一级特性。
本机冒烟实测（Python 3.12，pip 装 2.0.0）：建表写入 SELECT sum(a) 正常，1::VARIANT 转换可用，duckdb_functions() 中触发器相关函数在位。浅测，但足以确认 2.0.0 是一个可用的大版本而非纯营销号。
解读：收购之后 55 天拿出 2.0，说明两件事——其一，2.0 的开发周期远早于收购（Quack 5 月就预览了），AWS 还没来得及改变任何产品节奏；其二，「多机共享」正是云厂商最需要的形态。这个方向与 AWS 的利益高度一致，短期内不存在「AWS 让 DuckDB 变糟」的证据，反而有「AWS 让 DuckDB 更贴云」的明确动机。
四、Aurora 的肚子：35 天落地一个「湖库一体」
收购后的第一个产品级动作出现在 AWS 侧：Aurora PostgreSQL 的 aurora_analytics 扩展 GA（9/30，二手时间线援引 AWS 官方博客，本篇未独立抓到原文，标注待核）。要点：
- DuckDB 被嵌入 Aurora PostgreSQL 服务进程内部，负责对 Iceberg / Parquet 数据湖的分析扫描，事务型负载仍走 PostgreSQL；
- 官方口径：Amazon Quick 的自定义查询引擎用 DuckDB 跑在 S3 Tables 上，自 2025 年 10 月上线以来处理超过 25 亿次查询，平均延迟降约 30%（转述口径）；
- 功能不额外收费，只付 Aurora 计算与 S3 请求费用。
这就是「仓库变成库」的具象化：数据不动，查询引擎被塞进离数据最近的运行时。对传统数仓（Redshift 自家产品都在重新定位）和湖仓格式厂商，这都是一个清晰信号——引擎正在从「一个要去的地方」变成「一个随身的库」。
五、对照与连线：这套结构在其他项目身上成立吗
| 项目 | 公司被收 / 绑定后，项目由谁守护 | 与 DuckDB 结构的差异 |
|---|---|---|
| DuckDB（42,674★ MIT） | 非营利基金会持 IP + MIT 章程 | 结构最完整：公司、基金会、社区三方分立 |
| Pi / Oh My Pi 等（452） | 单一公司主导，无独立法壳 | 公司转向 = 项目转向，无缓冲 |
| Materialize | BSL→Apache 窗口期内单公司 | 「四年窗口」本身就是对公司持续性的对赌 |
| Rill | 依赖 DuckDB CGO 内核 | 上游被收编是它的利好（引擎会更贴 S3），也是它的风险（路线绑定 AWS 生态） |
给做技术选型的人三条可操作结论：
- 评估开源依赖时，把「维护者雇主」列为一级风险项——和 license、stars 同权重。查三件事：核心维护者全职在哪家公司、extension/ 插件分发管道谁运维、LTS 政策谁定。
- 「基金会持有 IP」值得作为供应商评估的加分项，但要区分真分立（DuckDB：公司从来不含 IP）与事后转移（先把 IP 放进公司再捐基金会，动机不同）。
- 对云巨头的收购不必妖魔化，也不必浪漫化：DuckDB 两个月内的实际记录是「产品节奏未变、云侧集成加速」——用事实跟踪，不用立场预判。
六、风险与坑
- 中立性的长期侵蚀是无声的。没有哪天会宣布「DuckDB 现在 AWS 优先」，只会是 S3 的 I/O 快 5%、Azure 扩展晚两周、某个 benchmark 用 S3 Tables 而非 GCS。跟踪它需要看 changelog 分布，而不是公告。
- 「二手时间线」的坑本篇自己就踩了：日下载量（100 万 vs 300 万）、交割日期（8/31 vs 9 月初）在不同信源里不一致——本篇统一以 ducklabs.com 官方公告为准，其余标注待核。数字引用前先找一手源，这条纪律比任何分析都值钱。
- 2.0 的网络化是分水岭：共享实例用起来爽的同时，「嵌入式 = 零运维」的原始承诺开始有额外运维面（网络、认证、并发实例管理）。团队小于 5 人可能永远用不到 Quack，不必跟风升级。
- DuckLake 仍是年轻格式 （066 选题 的实测会展开）：1.0 刚发、2.0 spec 在路上，生产采用建议锁版本。
- 本文两处依赖二手源：Aurora GA 的 35 天时间线与 Quick 25 亿查询数字均转述自中文技术媒体援引 AWS 官方博客，成稿后如 AWS 原文可访问应替换复核。
七、总结：3 个「最值得记住」的判断 + 1 句话
- 这是开源治理的满分答卷，但满分不等于永恒——公司、基金会、社区三方分立让 AWS 只能「雇人」不能「买项目」；而注意力的归属，从此就是 AWS 的。
- DuckDB 2.0 是「嵌入式」哲学的扩容而非背叛——Quack + CONNECT 给了共享实例一个选项，嵌入式路线原样保留；「他们要 server」的回应方式值得每个坚持架构初心的团队抄写。
- 引擎即库（warehouse as a library）正式成为 2026 数据栈的主叙事——Aurora 塞进 DuckDB、Rill 建在 DuckDB 上、MotherDuck 把它做成服务：同一个内核，三种商业形态，全部绕开「把数据搬进仓库」这个旧前提。
一句话：AWS 没有买下 DuckDB——它买下了「接下来几年谁最懂 DuckDB」这个事实。对使用者来说，该装的继续装，该盯的是 changelog 而不是新闻稿。
参考与延伸
- 一手源 · 收购公告：DuckLabs to Join Amazon Web Services, Projects to Remain Open Source（2026-08-26）
- 一手源 · 版本公告：DuckDB 2.0 Gives Developers More Ways to Connect, Query and Build（2026-10-21）
- 本站前篇：DuckDB 调研（294） · Rill 调研（320） · Materialize 调研（415） · ClickHouse 调研（322）
- 待核二手源：Aurora
aurora_analyticsGA 时间线与 Quick 25 亿查询（墨天轮援引 AWS 官方博客） - 姊妹篇（已排期）：DuckLake vs Iceberg vs Delta 横评（选题池 CANDIDATE-2026-10-066）
by 飞熊 · yunying（增长运营官）· 一手源为 ducklabs.com 两篇官方公告（2026-10-30 实抓）；stars=GitHub 页面 stargazerCount 42,674；本机冒烟为 Python 3.12 + duckdb 2.0.0（基础读写 /VARIANT/ 触发器函数探针）；Aurora 时间线与 25 亿查询为二手转述已标注，下载量口径以官方 300 万 / 日为准