每天，超过100万次下载请求指向同一个数据库引擎——DuckDB。根据PyPI（Python包索引）下载统计数据，DuckDB在2026年的日均下载量已突破100万次（来源：pypistats.org，2026年8月数据；DuckLabs官方博客亦多次引用此数据）。这个数字没有经过任何企业采购流程的过滤，没有经过CTO的审批签字，没有经过供应商评估委员会的投票。它们来自独立开发者的pip install duckdb，来自数据科学家Jupyter Notebook里的一行import语句，来自嵌入到SaaS产品后端的静默依赖。这是一种绕过所有传统软件销售漏斗的渗透方式——当AWS决定收购DuckLabs时，它买下的不是一个数据库产品，而是一个已经深植于全球数据工程师工作流中的事实标准。

2026年，AWS宣布与DuckLabs签署收购协议。DuckLabs是DuckDB背后的商业公司，由Hannes Mühleisen和Mark Raasveldt创立。收购完成后，两位创始人将继续领导团队和开源项目，DuckDB保持MIT许可证授权，由独立的DuckDB基金会管理。(来源: aboutamazon.com, AWS官方公告; ducklabs.com, DuckLabs官方博客)

这不是一次普通的云厂商吞并开源项目的故事。这是一次精心设计的「买公司不买项目」的新型收购范式，也是AWS将S3从被动存储层进化为主动分析平台的战略终局。

一、DuckDB是什么：SQLite的分析孪生体

要理解这次收购的重量，首先要理解DuckDB解决了什么问题。

DuckDB诞生于荷兰国家数学与计算机科学研究中心（Centrum Wiskunde & Informatica，简称CWI）——这个机构同样是Python编程语言的发源地。Hannes Mühleisen和Mark Raasveldt在CWI的数据库架构研究组中开发了DuckDB的原型，其设计哲学可以用一句话概括：成为分析查询领域的SQLite。(来源: ducklabs.com; aws.amazon.com/blogs/big-data)

SQLite是全球部署量最大的数据库——它嵌入在每一部手机、每一个浏览器、每一个IoT设备中。它的成功在于「零配置、嵌入式、单文件」的极简设计。但SQLite是为事务处理（OLTP）优化的行存储引擎，面对分析查询（OLAP）——涉及大量列扫描、聚合、窗口函数——它的性能远非最优。

DuckDB填补了这个空白。它是一个进程内（in-process）的列式分析数据库，不需要服务器、不需要安装守护进程、不需要网络连接。你可以在Python脚本中直接import duckdb，对本地Parquet文件、CSV文件、甚至远程S3上的数据执行SQL查询，性能可以达到传统分布式系统在中小数据集上的水平——甚至更快。

这里有一个被行业长期忽视的真相：企业中80%的分析查询处理的数据量不超过100GB。但为了处理这些查询，组织部署了Spark集群、Hadoop生态、或者按查询量计费的云数据仓库。这些系统设计目标是PB级横向扩展，但它们无法有效「向下扩展」（scale down）。一个只需要扫描500MB数据的查询，在Spark上可能需要30秒的集群启动时间，而在DuckDB上只需要0.3秒。(来源: aws.amazon.com/blogs/big-data, AWS官方博客提及DuckDB解决”scale down”问题)

AWS大数据副总裁Swami Sivasubramanian在官方博客中明确指出了这一点：传统大数据工具无法有效处理小规模查询，而这恰恰是绝大多数实际分析工作的场景。DuckDB的出现，让「笔记本电脑上的数据仓库」成为可能。

DuckDB的技术特性包括：

  • 列式向量化执行引擎：采用向量化处理（vectorized execution），每次处理一批数据而非逐行处理，充分利用现代CPU的SIMD指令和缓存层级
  • 零依赖嵌入式部署：单个库文件，支持C/C++、Python、R、Java、Node.js、Rust等多种语言绑定
  • 直接查询开放格式：原生支持Parquet、CSV、JSON、Apache Iceberg、Delta Lake等格式，无需ETL导入
  • MIT许可证：最宽松的开源许可，允许任何商业使用、修改、分发，无需开源衍生代码

最后一点至关重要。MIT许可意味着任何公司都可以将DuckDB嵌入其商业产品中而无需支付许可费或开源自己的代码。这解释了为什么DuckDB的日下载量能突破百万——它不仅被终端用户直接使用，更被大量SaaS产品、BI工具、数据管道框架作为底层引擎嵌入。

二、为什么AWS要「买」而不只是「用」

AWS完全可以在不收购DuckLabs的情况下使用DuckDB。MIT许可证赋予了这个权利。事实上，AWS与DuckLabs的合作早在2024年就已经开始——Amazon VP Andy Warfield明确提到双方的技术合作始于2024年。(来源: aboutamazon.com, AWS官方公告)

那么，为什么要花钱收购一个你已经可以免费使用的项目背后的公司？

答案在于三个层面：

第一层：人才与路线图控制

DuckDB的核心竞争力不在代码本身——代码是开源的，任何人都能fork。核心竞争力在于Hannes Mühleisen和Mark Raasveldt以及他们团队对查询优化器、执行引擎、存储格式的深度理解和持续创新能力。收购DuckLabs，AWS获得的是这个团队未来5-10年的创新输出，以及对DuckDB技术路线图的影响力（尽管不是控制权，因为基金会独立）。

这是一种微妙但关键的区别：AWS不需要「控制」DuckDB的开源方向，但它需要确保DuckDB的演进方向与AWS的存储和计算架构高度兼容。通过将DuckLabs团队纳入AWS，这种对齐变成了组织内部的自然协作，而非跨公司的商业谈判。

第二层：S3的分析层进化

AWS的数据基础设施战略有一条清晰的20年演进线：

  • 2006年：S3发布——对象存储，数据的终极归宿
  • 2009年：EMR发布——在S3上运行Hadoop/Spark
  • 2012年：Redshift发布——托管数据仓库
  • 2016年：Athena发布——无服务器SQL查询S3数据
  • 2023-2024年：S3 Tables发布——S3原生支持Apache Iceberg表格式
  • 2026年：收购DuckLabs——将高性能分析引擎直接集成到存储层

这条线的逻辑终点是什么？让分析在数据所在的地方直接发生，消除数据移动。

S3 Tables已经让S3从「存储桶」进化为「表存储」——数据以Iceberg格式组织，具备schema、分区、时间旅行等表语义。但S3 Tables本身不执行查询。DuckDB恰好是在本地直接查询Iceberg/Parquet文件的最佳引擎。两者的结合意味着：用户可以在S3上直接运行分析查询，无需将数据复制到Redshift，无需启动EMR集群，无需为Athena的按扫描量计费模型买单。(来源: aws.amazon.com/blogs/big-data, AWS官方博客讨论S3 Tables与DuckDB的结合)

Andy Warfield在AWS官方公告中明确表示，DuckDB与S3 Tables的结合代表了AWS对「分析即存储」愿景的实现路径。

第三层：防御性收购——阻止竞争对手获得关键拼图

如果AWS不买DuckLabs，谁会买？Google Cloud？Microsoft Azure？Snowflake？Databricks？

DuckDB的日下载百万次意味着它已经是数据工程师的默认工具。任何云厂商获得DuckLabs团队，都能在其存储层之上构建类似的「嵌入式分析」体验。对AWS来说，S3是其最大的数据护城河——全球最大的数据存储池。让DuckDB与S3的集成成为最优体验，是保护这条护城河的关键。

三、「买公司不买项目」：开源收购的新范式

这次收购最值得分析的不是「AWS买了什么」，而是「AWS承诺不做什么」。

根据AWS官方公告和DuckLabs官方博客，收购后的安排包括：(来源: aboutamazon.com; ducklabs.com; aws.amazon.com/blogs/big-data)

  1. DuckDB保持MIT许可证开源——不会改为Apache 2.0、SSPL、BSL或任何更限制性的许可
  2. DuckDB由独立的DuckDB基金会管理——AWS不获得基金会的治理控制权
  3. Hannes Mühleisen和Mark Raasveldt继续领导团队和项目——不是被吸收进AWS的某个产品组
  4. DuckDB的开源发展方向不变——社区贡献者、第三方集成商的权利不受影响

这种安排在云厂商收购开源公司的历史中几乎没有先例。让我们对比几个历史案例：

Elastic被AWS「复制」而非收购（2019-2021）：AWS基于Elasticsearch的开源代码创建了OpenSearch分支，Elastic被迫将许可证从Apache 2.0改为SSPL以自保。这是开源社区最恐惧的场景——云厂商不付费使用开源项目的商业价值。

Red Hat被IBM收购（2019）：IBM以340亿美元收购Red Hat，承诺保持其独立运营。但随后几年，Red Hat的开源策略发生了微妙变化——CentOS被转为CentOS Stream（滚动发布），社区感知到的独立性下降。

HashiCorp被IBM收购（2024）：在被收购前，HashiCorp已经将Terraform等产品从MPL改为BSL许可证，引发社区fork（OpenTofu）。收购本身加速了开源社区的信任危机。

MongoDB的SSPL转向（2018）：为防止AWS等云厂商提供托管MongoDB服务而不回馈社区，MongoDB将许可证改为SSPL——实质上禁止云厂商提供「MongoDB即服务」。

DuckDB的情况根本不同。MIT许可证是最宽松的开源许可——它不能被「收回」或「改变」（已发布版本的许可不可撤销）。即使AWS理论上可以影响未来版本的许可选择，DuckDB基金会的独立性和MIT许可的社区期望使得许可变更的政治成本极高。

这里的关键洞察是：AWS收购DuckLabs的价值不在于获得对DuckDB代码的排他性控制（MIT许可下这不可能），而在于获得对DuckDB「下一步做什么」的优先影响力。

当DuckLabs团队在AWS内部工作时，他们自然会优先优化DuckDB与S3、S3 Tables、Lambda、Glue等AWS服务的集成。这不需要改变许可证，不需要限制竞争对手使用DuckDB——只需要让DuckDB在AWS生态中的体验比在任何其他环境中更好。

这是一种比许可证武器更优雅、更持久的竞争策略：不是阻止别人用，而是让自己用得最好。

四、对立视角：这真的对开源生态「好」吗？

乐观视角：开源项目的最佳结局

支持者认为，DuckLabs的收购代表了开源项目商业化的理想模式：

  • 创始人获得经济回报（截至本文发布时暂无公开的收购金额数据）
  • 团队获得AWS的资源（计算、存储、工程人才）来加速DuckDB开发
  • 开源社区不受影响——MIT许可不变，基金会独立
  • DuckDB获得AWS的分发渠道——AWS的数百万客户将更容易接触到DuckDB

从DuckLabs的角度，这可能是最优解。作为一家开源公司，DuckLabs面临所有开源商业化的经典困境：MIT许可意味着任何人都可以免费使用你的核心技术，你的商业模式只能建立在「额外价值」上（企业支持、托管服务、专有扩展）。但DuckDB的嵌入式特性使得「托管服务」模式天然不适用——用户选择DuckDB恰恰是因为它不需要服务器。

加入AWS意味着DuckLabs不再需要解决「如何把免费用户转化为付费客户」的问题。团队可以专注于他们最擅长的事：构建世界上最好的嵌入式分析引擎。

悲观视角：又一个开源项目被大厂「中性化」

批评者可能指出几个风险：

1. 路线图偏移风险：即使DuckDB保持开源，当核心开发者在AWS工作时，他们的优先级不可避免地会向AWS的需求倾斜。对Google Cloud Storage的优化、对Azure Blob的支持、对竞争性数据格式的兼容——这些可能不再是优先事项。

2. 社区贡献动力下降：当一个开源项目的核心团队属于单一大公司时，外部贡献者可能感到自己的贡献是在「为AWS免费打工」。Linux之所以保持健康的多方贡献者生态，恰恰是因为没有任何单一公司拥有Linus Torvalds的雇佣关系（他由Linux基金会支持）。

3. 「独立基金会」的实质权力问题：DuckDB基金会管理项目的开源治理，但如果90%的核心提交者都是AWS员工，基金会的「独立性」在实践中意味着什么？治理结构的形式独立不等于实质独立。

我的判断

我认为这次收购对DuckDB生态的短期影响是正面的，中长期存在路线图偏移的真实风险，但不太可能出现许可证变更或项目封闭的极端情况。

原因如下：

MIT许可的不可撤销性意味着，即使AWS未来做出任何不利于社区的决定，社区随时可以fork当前版本并独立发展。这与Elasticsearch/OpenSearch的情况不同——当时Elastic主动改变了许可证。在DuckDB的情况下，「核选项」（fork）始终掌握在社区手中，这构成了对AWS行为的有效制约。

但路线图偏移几乎是确定的。不是因为AWS会「恶意」忽视其他平台，而是因为组织内部的自然激励结构：当你的工资由AWS发放时，优化S3集成的优先级自然高于优化GCS集成。这不是阴谋，这是人性。

五、分析基础设施的权力重组：S3 + DuckDB对Snowflake和Databricks的真实威胁

让我们把视角拉远，看看这次收购在更大的数据基础设施竞争格局中意味着什么。

当前格局

过去10年，数据分析基础设施的核心商业模式是「计算-存储分离」的云数据仓库/数据湖仓：

  • Snowflake：将数据存储在云对象存储（包括S3）上，通过专有计算层提供SQL分析，按计算资源使用量收费
  • Databricks：基于Apache Spark和Delta Lake，提供统一的数据湖仓平台，同样按计算量收费
  • AWS Redshift：AWS自己的数据仓库产品，近年来也转向计算-存储分离架构
  • Google BigQuery：按扫描数据量收费的无服务器模式

这些产品的共同特点是：你必须把数据「交给」它们的系统，然后为查询付费。即使数据物理上存储在S3上，你也需要通过它们的计算层来访问。

DuckDB + S3 Tables改变了什么

DuckDB的嵌入式特性意味着一种全新的分析模式：

  1. 数据存储在S3 Tables中（Iceberg格式，具备完整表语义）
  2. 用户在自己的应用程序/笔记本/Lambda函数中嵌入DuckDB
  3. DuckDB直接从S3读取数据并在本地执行查询
  4. 无需启动集群，无需连接数据仓库，无需为「计算层」付费

这对Snowflake和Databricks的威胁不在于取代它们处理PB级数据的能力——DuckDB是单机引擎，不做分布式。威胁在于蚕食它们80%的查询场景。

回到前面提到的事实：企业中80%的分析查询处理的数据量在DuckDB单机可以高效处理的范围内。如果这80%的查询可以通过嵌入式DuckDB直接在S3上完成，那么Snowflake和Databricks的计费查询量可能大幅下降。

更具体地说，这种威胁体现在几个场景：

场景1：数据应用的嵌入式分析 一个SaaS产品需要为用户提供分析仪表盘。传统方式是连接Redshift或Snowflake，为每个查询付费。新方式是在应用后端嵌入DuckDB，直接查询S3上的Parquet/Iceberg文件。对于中小规模数据，这更快、更便宜、更简单。

场景2：数据科学家的探索性分析 数据科学家在Jupyter Notebook中探索数据。传统方式是连接Spark集群或Snowflake。新方式是import duckdb，直接查询S3路径。零启动时间，零额外成本（只付S3 GET请求费用）。

场景3：ETL管道中的转换步骤 数据管道中的SQL转换步骤。传统方式是通过dbt连接Snowflake/BigQuery执行。新方式是在Lambda函数或容器中嵌入DuckDB执行转换，结果写回S3。按Lambda执行时间付费，通常远低于数据仓库的计算费用。

Snowflake和Databricks的反驳

公平地说，Snowflake和Databricks的支持者会提出几个反论点：

1. 「DuckDB不做分布式，大数据场景它无能为力」——这是事实，但忽略了一个关键点：大多数企业的大多数查询不需要分布式。DuckDB不需要取代Spark处理PB级ETL，它只需要让用户意识到「这个查询其实不需要Spark」。

2. 「企业需要治理、安全、审计、协作」——这是Snowflake和Databricks的真正护城河。DuckDB是一个引擎，不是一个平台。它没有用户管理、权限控制、查询审计、数据血缘等企业功能。但AWS可以在S3 Tables层面提供这些功能——IAM权限、CloudTrail审计、Lake Formation治理——而让DuckDB只负责计算。

3. 「嵌入式模式增加了运维复杂度」——当每个应用都嵌入自己的DuckDB实例时，缺乏集中的查询优化、资源管理和成本控制。这是真实的挑战，也是AWS可能通过托管服务解决的方向。

我的判断

DuckDB + S3 Tables不会「杀死」Snowflake或Databricks，但会重新定义它们的价值主张边界。它们将被迫从「所有SQL分析的默认选择」退守到「大规模、高治理需求、多用户协作场景的最佳选择」。这意味着它们的可寻址市场（TAM）可能比当前估值隐含的假设更小。

对AWS来说，这是一个精妙的「降维打击」：通过让简单分析查询在S3层直接完成，AWS不需要让Redshift打败Snowflake——它只需要让一大部分查询根本不需要经过任何数据仓库。用户为S3存储付费，为S3 GET请求付费，为Lambda计算付费——AWS的营收不会减少，只是从「Redshift/Athena收入」转移到「S3 + Lambda收入」。而Snowflake和Databricks的收入则是净减少。

六、技术深潜：DuckDB为什么这么快

理解DuckDB的竞争力需要理解它的几个关键技术决策：

向量化执行 vs 火山模型

传统数据库（包括早期的PostgreSQL）使用「火山模型」（Volcano model）执行查询：每个操作符一次处理一行数据，通过next()调用逐行传递。这种模型的问题是每行数据都有函数调用开销，且无法利用现代CPU的SIMD（Single Instruction, Multiple Data）指令。

DuckDB采用向量化执行：每个操作符一次处理一批数据（通常是1024-2048行的向量）。这带来两个优势：

  • 函数调用开销被摊薄到整个向量上
  • 向量操作可以直接映射到CPU的SIMD指令（如AVX-512），单条指令处理多个数据点

在分析查询中，这种差异可以带来显著的性能提升。根据DuckDB官方技术博客的TPC-H基准测试，在Q1类聚合查询中，DuckDB相比PostgreSQL的行式执行提升约30-50倍；在列扫描密集型查询中，性能提升可达100倍以上（来源：Mark Raasveldt & Hannes Mühleisen, “DuckDB: an Embeddable Analytical Database”, SIGMOD 2019）。

列式存储的缓存友好性

DuckDB使用列式存储格式，同一列的数据在内存中连续排列。当执行SELECT AVG(price) FROM orders时，CPU只需要顺序扫描price列的连续内存，缓存命中率极高。相比行式存储（每行的所有列交错排列），列式存储在分析查询中的缓存效率可以高出一个数量级。

自适应查询优化

DuckDB的查询优化器包含多项针对嵌入式场景的优化：

  • 延迟物化（Late Materialization）：尽可能延迟将列数据组装成完整行，减少内存使用
  • ART索引（Adaptive Radix Tree）：针对现代CPU缓存层级优化的索引结构
  • 并行执行：自动利用多核CPU并行执行查询的不同阶段
  • Parquet谓词下推：直接在Parquet文件的元数据层面过滤不需要的行组（row groups），避免读取不相关数据

与S3的集成优化

DuckDB对远程对象存储的查询做了专门优化：

  • HTTP Range请求：只读取Parquet文件中需要的列和行组，而非下载整个文件
  • 并行预取：在处理当前数据块时，并行预取下一批数据块
  • 元数据缓存：缓存Parquet文件的footer和column chunk元数据，避免重复的网络往返

当DuckDB团队在AWS内部工作时，这些与S3的集成优化将获得更深层次的可能性：直接利用S3的内部API、与S3 Express One Zone（低延迟存储层）的深度集成、甚至在S3的计算节点上直接运行DuckDB的查询片段。这些是外部公司无法做到的优化，也是收购的真正技术红利。

七、AWS 20年数据战略的终局

让我们重新审视AWS的数据基础设施演进，但这次从一个不同的角度：AWS一直在试图让「数据引力」为自己服务。

「数据引力」是一个业界概念：数据因为体积大、移动成本高，会像天体一样吸引应用和服务向它靠拢。AWS的S3是全球最大的数据引力中心——数以EB计的数据存储在S3上。AWS过去20年的策略一直是：既然数据已经在S3上，就让所有分析工具来S3旁边运行。

  • EMR：把Hadoop/Spark搬到S3旁边
  • Redshift Spectrum：让Redshift直接查询S3
  • Athena：无服务器查询S3
  • S3 Tables：让S3本身成为表

但所有这些方案都有一个共同的局限：它们是AWS管理的服务，用户必须通过AWS的服务边界来访问数据。DuckDB改变了这个范式——它让用户在自己的进程中直接查询S3数据，绕过了AWS服务层。

从表面看，这对AWS不利——用户不再需要为Athena按扫描量付费。但从更深层看，这对AWS极其有利：

  1. 降低了使用S3数据的门槛——更多数据会被存入S3，因为分析变得更简单
  2. 增加了S3的API调用量——每次DuckDB查询都会产生S3 GET请求
  3. 强化了S3的数据引力——当DuckDB + S3的体验最好时，用户更不会把数据移到GCS或Azure Blob
  4. 减少了对竞争对手数据仓库的依赖——用户不再需要把数据从S3复制到Snowflake

Andy Warfield在AWS官方公告中的表述很有深意：他谈到的是「让客户更容易在数据所在的地方进行分析」——这不是关于卖更多的计算服务，而是关于让S3成为不可替代的数据平台。(来源: aboutamazon.com)

这是AWS数据战略的真正终局：S3不再只是存储，它是分析平台本身。计算发生在用户侧（通过嵌入式DuckDB），存储和数据管理由S3提供。AWS赚的是存储费和API调用费——这是最稳定、最可预测、利润率最高的收入。

八、对AI时代数据工程的启示

最后，让我们把这次收购放在AI时代的背景下审视。

大语言模型（LLM）和AI Agent的兴起正在改变数据分析的交互方式。传统的数据分析流程是：人类写SQL→数据库执行→返回结果。新的流程是：人类用自然语言提问→AI Agent生成SQL→数据库执行→AI Agent解释结果。

在这个新流程中，DuckDB的嵌入式特性具有独特优势：

1. AI Agent的本地分析能力：一个AI Agent可以在自己的进程中嵌入DuckDB，直接对数据执行分析，无需管理数据库连接、认证、网络延迟。这使得AI Agent可以更快速、更自主地完成数据探索任务。

2. 边缘分析：当AI推理从云端向边缘迁移时（本地LLM、设备端AI），数据分析也需要在边缘完成。DuckDB的零依赖、嵌入式特性使其成为边缘AI分析的天然选择。

3. 数据准备的民主化：AI时代需要大量的数据准备工作——清洗、转换、特征工程。DuckDB让这些工作可以在笔记本电脑上完成，而不需要连接到昂贵的云数据仓库。这降低了AI项目的启动门槛。

AWS收购DuckLabs，在AI背景下有一个额外的战略含义：当AI Agent成为数据分析的主要消费者时，嵌入式分析引擎比服务器式数据仓库更适合AI原生的工作流。AWS通过拥有DuckDB团队，确保了在AI时代的数据分析入口——无论是人类用户通过DuckDB查询S3，还是AI Agent通过DuckDB查询S3，AWS都是数据层的提供者。

结语：So What

对于不同角色的读者，这次收购意味着不同的事情：

如果你是数据工程师/分析师：DuckDB不会消失，MIT许可不会改变。短期内你会看到DuckDB与AWS服务（特别是S3 Tables）的集成变得更加丝滑。继续使用DuckDB是安全的选择。但要注意：如果你的工作流高度依赖DuckDB与非AWS存储的集成（如GCS、Azure Blob），未来的优化优先级可能会有所偏移。

如果你是Snowflake/Databricks的用户或投资者：这是一个值得认真评估的竞争威胁信号。不是因为DuckDB会在短期内取代这些平台，而是因为AWS现在有了一个明确的策略来让「简单分析」绕过数据仓库直接在S3上完成。评估你的查询工作负载中有多少比例可以被DuckDB + S3 Tables替代——这个比例可能比你想象的大。

如果你是开源创业者：DuckLabs的结局（被大厂收购且保持开源独立性）可能是MIT许可开源项目的最佳商业化路径之一。截至本文发布时，收购金额尚无公开披露。但参考可比收购案例——如Databricks在2023年以13亿美元收购MosaicML，以及AWS此前对多个开源项目背后公司的收购价格区间——DuckLabs的收购估值可能在数亿到数十亿美元之间（作者推算，非官方数据）。值得注意的前提是：DuckDB之所以能谈到保持开源独立性的条款，是因为其日下载百万次的开发者生态让AWS不敢破坏社区信任。没有社区杠杆的开源项目，在收购谈判中没有这种议价能力。

如果你是云基础设施的战略观察者：这次收购标志着云厂商竞争的新阶段——从「谁的计算服务更好」转向「谁的存储层能直接提供分析能力」。存储是云计算中粘性最高、利润率最高的业务。当存储层可以直接承载分析工作负载时，独立的计算层（数据仓库、查询引擎）的价值主张就会被压缩。

AWS收购DuckLabs不是一个孤立事件——它是数据基础设施「分析下沉到存储层」大趋势的标志性时刻。当全球最大的对象存储服务获得了全球最受欢迎的嵌入式分析引擎的核心团队，「在数据所在的地方分析数据」从口号变成了现实。

剩下的问题只有一个：Google和Microsoft将如何回应？

参考资料

  1. AWS to acquire DuckLabs, the company behind DuckDB — Amazon, 2026
  2. AWS and DuckLabs: Building the future of analytics together — AWS Big Data Blog, 2026
  3. DuckLabs is joining AWS — DuckLabs Official Blog, 2026

主题分类：技术突破/AI商业模式