2026年8月26日，Amazon Web Services做了一个让很多人感到意外的决定：买下DuckLabs——那家总部位于阿姆斯特丹、只有30多名员工、从不拿VC融资的开源数据库公司。意外的不是金额（未披露），而是标的本身。DuckDB是一款单机运行的嵌入式分析型数据库。它的核心卖点恰好是"你不需要服务器"。"不需要服务器"这句话，在一个靠卖云服务年营收超过1000亿美元的公司那里，听起来像一句挑衅。但AWS还是把它买了。
现象：DuckDB到底是个什么存在？
DuckDB不是一个传统的数据库。如果你用"数据库"来理解它，你会完全搞错它的定位。
它是一个嵌入式SQL OLAP数据库——技术圈更喜欢的说法是"SQLite for analytics"。它不作为一个独立进程运行，而是嵌入到宿主程序（比如Python进程）内部。这意味着：不需要安装DuckDB服务器，不需要配置连接，不需要管理集群。你只需要pip install duckdb，加载一个扩展，就可以对远程S3上的Parquet文件跑SQL查询——而且很多时候，比从Snowflake或Redshift拉数据还快。
这种"零基础设施"的数据分析体验，让DuckDB在过去几年中以病毒式速度扩散。DuckLabs官方数据显示，DuckDB日均下载量超过100万次。在数据基础设施领域，这是一个惊人的数字。
DuckDB的流行并非偶然。它捕捉到了一个被主流云厂商长期忽视的需求：开发者希望在本地快速分析数据，而不必经过繁琐的ETL管道、等待数仓集群冷启动、或者为每一次临时查询支付云上扫描成本。
AWS早已注意到这一点。2026年3月，AWS在内部推广了Row Zero——一个能在云上打开十亿行数据集的电子表格工具。但Row Zero解决的只是"前端交互"问题，DuckDB解决的是"后端分析引擎"问题。收购DuckLabs，AWS拿到了那个缺失的核心组件。
更关键的是，这个"缺失组件"正在快速进化。2026年5月12日，DuckDB团队发布了名为Quack的网络协议，为DuckDB引入了客户端-服务器模式。它的口号是："DuckDB as a server"。一个曾经只做本地嵌入式的数据库，开始向"服务器模式"演进。作为DuckDB 2.0路线图的关键组成部分，Quack意味着DuckDB将成为一个既能本地运行、也能作为数据服务存在的混合体。
为什么说DuckDB是"反云"的？
要理解这笔收购的真正含义，必须先理解DuckDB与云计算之间的底层张力。
主流云数据平台——无论是AWS的Redshift和Athena、Google的BigQuery还是Snowflake——都遵循同一个流量逻辑：数据在云上，计算在云上，查询结果从云上返回。你每一次查询，每一次分析，都需要经过云端的计算资源，而这些消耗都会变成你的账单。
DuckDB完全相反。它的核心理念是：数据可以在云上（S3/对象存储），但计算在本地。DuckDB直接读取S3上的Parquet文件，在本地内存中完成聚合、过滤、连接——不需要启动任何云上计算集群。
这意味着什么？意味着如果你用DuckDB来跑一个大型数据集分析，你的成本结构会变成：存储费（固定）加网络传输费（固定）——几乎为零的增量计算消耗。而同样的分析在AWS Athena上跑，查询费用为每TB扫描数据5美元；在Redshift上，你要为一个预留集群付数千甚至上万美元月费。
这就是DuckDB对云厂商的"威胁"本质：它把分析型计算从云端重新拉回了本地，从而绕过了云上最赚钱的那一层——计算层。
MotherDuck CEO Jordan Tigani在收购消息后的一篇博文中一针见血：
"That's Amazon's playbook, after all: wait until an open source project gets big enough, then launch it as a service. After all, they're not acquiring Duck Labs just because they love open source."
翻译过来：亚马逊的剧本一直是——等一个开源项目足够大了，就拿它做成一个云服务。他们买DuckLabs不是单纯因为热爱开源。
AWS的深层焦虑：数据层的"去中心化"浪潮
AWS收购DuckLabs，表面上是技术补强，本质上是对一个正在发生的行业趋势的回应。
过去十年，数据分析的主流范式是"中心化"：将所有原始数据汇集到一个数据仓库或数据湖中（Snowflake、Redshift、Google BigQuery），然后统一进行ETL、建模、分析和治理。这套架构的优点是统一治理和数据一致性，缺点是成本高昂、灵活性差、查询等待时间长。
但这个范式正在被挑战。三股力量同时在推。
第一，数据量的爆炸式增长。AI训练和推理产生的数据量级远超传统数仓的处理边界。把每一条数据都搬进数仓，成本上已经不可持续。
第二，数据格式的开放化。Apache Parquet、Iceberg、Delta Lake等开放格式的普及，使得数据可以在不锁入任何一个数仓的情况下被直接查询。数据驻留在S3上，分析引擎可以是一个轻量级的本地进程（DuckDB），也可以是一个分布式SQL引擎（Trino/Presto）。
第三，AI Agent对分析模式的颠覆。AWS VP Mai-Lan Tomsen Bukovec在收购公告中指出，DuckDB天然适合AI Agent的使用模式——"AI Agent查询数据的方式和人差不多，通过反复试验和探索来理解数据"。在Agent世界，高频、低延迟、细粒度的查询需求远超传统BI报表场景。每次查询都走云上计算层，成本会迅速失控。
这三股力量汇合的结果是：数据分析正在从"中心化计算"向"原地计算"迁移。你的数据可以安静地躺在S3上，由各种轻量级引擎在本地或边缘完成分析。DuckDB就是这种新范式的代表性工具。
对AWS而言，这个趋势是一把双刃剑。一方面，S3作为数据存储层会因此更加重要（存储费是AWS的核心收入之一）。另一方面，如果所有分析计算都在本地完成，AWS生态中最赚钱的计算服务（Athena、Redshift、EMR、Glue）的市场空间会被大幅压缩。
收购DuckLabs，AWS的战略意图变得清晰：与其让DuckDB成为绕开AWS计算层的外部威胁，不如把它变成AWS生态的一部分。
MotherDuck的尴尬角色
这笔交易中还有一个被夹在中间的玩家：MotherDuck。
MotherDuck是由Jordan Tigani（前Google BigQuery创始工程师）于2022年创立的公司，核心产品是在云端运行DuckDB——把DuckDB的"本地分析"体验搬到云上，提供Serverless的托管服务。MotherDuck已累计融资超过1亿美元，投资方包括Felicis、a16z、Madrona、Altimeter等一线VC。
MotherDuck的尴尬在于：它和DuckLabs有长达四年的深度合作关系，其三名工程师位列DuckDB社区外部贡献者前十名。但MotherDuck的商业模式的本质是"把DuckDB变成云服务"——恰好就是AWS现在要做的同一件事。
收购消息公布后，MotherDuck立即宣布将接管DuckDB的企业支持服务。此前为了避免与DuckLabs竞争，MotherDuck主动避开了这一业务线。Tigani在博文中透露，此举获得了Mühleisen和Raasveldt的明确授权。
Tigani在公开表态中展现了极强的姿态管理能力："We welcome the competition." 但熟悉云市场的人都知道，MotherDuck作为一家独立初创公司，与AWS正面竞争云托管分析市场，前景并不乐观。AWS可以用成本价（甚至亏损）将DuckDB作为S3的内置分析引擎捆绑销售，而MotherDuck必须在同样的产品上维持正毛利。
开源项目与商业巨头的"危险共舞"
DuckDB的归属问题在开源社区引起了广泛讨论，这是有理由的。
AWS有"拥抱—扩展—熄灭"的前科。Elasticsearch的案例至今令人记忆犹新：AWS在2019年推出自家托管的Elasticsearch服务，随后与Elastic公司发生许可证争议，最终Elastic在2021年将许可证从Apache 2.0改为SSPL。尽管后来双方和解，但那次冲突深刻揭示了开源项目与云巨头之间"合作与竞争并存"的复杂关系。
不过，DuckDB的情况有几个重要的不同点。
第一，DuckDB的知识产权归DuckDB Foundation所有，而非DuckLabs公司。DuckLabs只是DuckDB的"核心开发团队"，不是"所有者"。DuckDB Foundation的章程确保DuckDB在MIT许可证下永久开源。Tigani在博文中用了"iron clad control"来形容基金会对其IP的控制力。
第二，收购后DuckLabs将以全资子公司的形式独立运营，核心团队继续留在阿姆斯特丹，Mühleisen和Raasveldt继续主导技术方向。Amazon承诺DuckDB继续开源、保持MIT许可证，并宣布将在基金会下成立技术顾问委员会（Technical Advisory Board），吸纳社区核心成员参与项目方向决策。
第三，DuckDB的技术哲学（嵌入式、零基础设施）与AWS的商业模式（托管、付费服务）之间存在结构性张力。如果AWS强行把DuckDB改造成"必须配合AWS服务才能用"的形态，反而可能杀死DuckDB最核心的竞争力——而这正是它被收购的价值所在。
但这并不意味着没有风险。技术顾问委员会的设立可以被视为一种制衡机制——确保AWS无法单方面主导DuckDB的演进路线。DuckDB的案例可能成为开源项目治理的新范式：把开发公司卖给巨头，同时IP独立在基金会手中，技术方向由社区和顾问委员会共同决定。这种"公司被收购，项目仍独立"的模式，比Elasticsearch和MongoDB的对抗式演变要温和得多。
结论与展望
这笔交易可能产生三种影响。
对AWS而言，DuckDB将深度融入S3的数据分析体验。一个合理的推演是：未来的AWS控制台中，你可以直接在S3桶上运行SQL查询，无需启动Athena或Redshift，后台引擎就是DuckDB。这将使S3从一个"存储层"进化为一个"分析层"——让数据在存储原地就能被分析。
对Snowflake和Databricks而言，压力持续加大。S3加DuckDB的组合提供了"极简数据分析"的第三条路径：不需要管理集群、不需要预付费用、没有查询空闲成本。对于中长尾数据分析场景（临时查询、本地探索、轻量级BI），这个组合在经济性和易用性上的优势是碾压式的。
一个值得关注的时间节点是DuckDB 2.0正式发布。Quack协议的推出意味着DuckDB正式从"本地嵌入式"向"混合模式"演进——既可以在本地跑，也可以通过网络协议作为服务运行。DuckDB 2.0加Amazon S3的组合，可能是AWS给自己的"中心化计算"设下的最大挑战——而它选择主动拥抱这个挑战。
AWS买下的不是一个开源的数据库项目，而是一个让它在"原地计算"时代仍然能站在数据流中央的座位。在云计算的下一站，谁能在数据诞生的地方完成分析，谁就能定义这场游戏的规则。
快报