亚马逊买下DuckDB，到底图什么？

2026年10月，AWS宣布收购DuckLabs——嵌入式分析数据库DuckDB背后的公司。这条新闻在社交平台上只刷了半天，但资深数据圈的反应远比标题热闹：云巨头第一次把一个嵌入式分析引擎，装进了自家最主流的事务数据库里。同一时间窗口，PostgreSQL 18正式发布，开源数据库延续年度大版本节奏。

两件事单独看都平常，放在一起看，指向同一个判断：Postgres正在从「最受欢迎的关系型数据库」，变成整个数据栈的默认底座。而AWS，选择直接买下这块底座上最锋利的分析插件。

📦 第一刀：把分析引擎塞进事务大库

先看一个几乎所有Aurora用户都熟悉的场景。

你的业务库跑在Amazon Aurora PostgreSQL上，订单、用户、库存，样样都在里面。老板要看报表，分析师要做留存，BI同事拿着一堆聚合查询冲过来——DBA的第一反应永远是拦：别在主库上跑，会拖垮交易。于是经典流水线诞生了：CDC抽取、ETL搬运、数据落到Redshift或者Athena，再接BI工具。数据没出问题，链路先出了问题——延迟、成本、两套一致性的心智负担，全在这条管道上。

收购之后，这条链路的第一环开始松动。据官方披露，Aurora PostgreSQL已经拿到了收购后首个由DuckDB驱动的特性：分析能力直接进了库。这意味着什么？简单说，事务场景继续走Postgres内核，分析负载由内嵌的DuckDB引擎承接，数据不用再被大卸八块搬出去一趟。

从架构上讲，这是一笔性价比极高的买卖。DuckDB是列式存储加向量化执行的分析引擎，天生适合聚合扫描这类报表型负载；Postgres是行存的OLTP内核，天生不适合。过去HTAP（混合事务分析处理）这个概念喊了很多年，各家方案要么是两套系统硬拼，要么是在单一内核里做艰难的折中。AWS的路线更野：不改造内核，直接在数据库旁边挂一个嵌入式分析引擎，分工明确，互不拖累。

产业逻辑上，这标志着HTAP之争进入新阶段——比拼的不再是「谁在单一系统里做到了混合负载」，而是「谁把混合负载的体验做得最无感」。用户要的从来不是架构图上的漂亮，而是「我在主库里写个分析查询，它不崩、不贵、不用等T+1」。谁能把这个体验做成默认开关，谁就锁住了云上数据工作负载的第一入口。

💰 创始人留任：开源公司的又一次宿命落子

每一笔基础设施领域的收购，最值得看的都不是价格，而是条款。

这次的关键条款有三条：其一，DuckLabs联合创始人Hannes Mühleisen和Mark Raasveldt继续留在AWS旗下带队；其二，收购目的明确写着增强DuckDB的开发与影响力；其三，保持开源状态。

三条翻译成白话：AWS买的是团队、是方向、是社区信任，不是把代码锁进保险柜。这在当前的开源并购里算相当体面的安排，也是AWS能把这个消息平稳发出来的前提——如果条款里没有「保持开源」这一句，社区的反噬会立刻开始。

冰面之下才是这笔交易真正的分量。

DuckDB这些年在数据工程师群体里的渗透速度有目共睹：本地跑分析、Jupyter里直接查Parquet、把「SQLite for analytics」的定位打进了几乎所有数据从业者的工具箱。这类嵌入式引擎的商业模式一直是个难题——免费、单机、好用，意味着愿意付钱的企业客户天然稀少。独立公司靠支持和云服务变现，路能走，但慢。圈内流传的判断比较一致：对DuckLabs这样的团队而言，被一家拥有全球最大云分发网络的买家收编，是把影响力变现为「开发与触达」的最短路径；对AWS而言，则是用一笔收购补上了Postgres生态里最锋利的那把刀。

双方各取所需，唯一的变量是社区。开源项目被云厂商收购后，「中立性」这道坎永远绕不过去：DuckDB能否继续在其他云、其他数据库里保持一视同仁的支持？DuckLabs原团队在AWS体系内能否维持原有节奏？这两问的答案，将决定这笔收购是双赢叙事，还是又一次「开源被收编」的警示案例。

🐘 PostgreSQL：一个内核吃下整个数据栈

把镜头拉远，你会看到一幅更完整的图景：Postgres正在变成数据基础设施界的「内核」，所有能力都在往它身上长。

PostgreSQL 18的正式发布本身并不意外——一年一大版，是Postgres社区多年来的稳定节奏。真正值得注意的是节奏背后的信号：在商业数据库公司普遍拉长发布周期、把资源押向云服务的年代，一个纯开源项目还在按年交付大版本。这种工程纪律，是Postgres能够持续吸纳整个生态的前提。

更关键的是扩展体系。Postgres的extension机制允许第三方在不动内核的情况下往里挂能力：向量检索让它在AI时代接住了RAG场景，各类分析扩展不断把AP能力往库内搬。如今AWS把DuckDB接进来，等于官方下场给这条「库内分析」路线背书。生态位是这样迭代的：先有社区在边缘长出新能力，再有巨头把它变成默认能力——上一轮是PostGIS和地理数据，这一轮轮到DuckDB和分析。

把主流分析引擎放在「技术门槛—商业价值」的坐标系里，位置会很清晰：

DuckDB的技术门槛高（列式引擎、向量化执行，独立研发门槛极强），但作为单机嵌入式产品的直接商业价值有限——这正是它落在「潜力股」区间的原因。而AWS收购的本质，就是给这个高门槛、中价值的点，接上一条通往高商业价值的传送带：Aurora的装机量。用户不单独为DuckDB付费，但DuckDB让Aurora更难被替换，这就是云经济学的算账方式。

推演一步，Postgres内核+DuckDB引擎的组合，冲击的远不止Redshift自家兄弟。大量中低复杂度的分析场景，原本是Snowflake、Databricks们的入门盘——现在这部分需求可能根本不出库。数据栈的分层逻辑，正在被「库内闭环」一点点改写。

⚠️ 云厂商收编开源，临界点到了吗

「云厂商吃掉开源」不是新故事，但每一次发生，行业的紧张程度都在加码。

这次的特殊性在于：过去云厂商收编的多是基础软件公司（数据库、消息队列、网关），而DuckDB的位置更敏感——它是数据工具链的「最后一公里」，是每个数据工程师桌面上的常驻程序。谁控制了它，谁就站在了开发者工作流的起点，而不只是云端账单的末梢。

各方处境，摆在明面上：

据多位接近交易的行业人士观察，这次AWS在公告里高调写明「保持开源」，本身就是对社区情绪的预防性管理。这个措辞在十年前是不可想象的——那时候的主流剧本是拿走代码、闭源收费，逼得社区分化出各种许可证攻防。如今云巨头学会了先交出「不闭源」的承诺再谈整合，说明开源社区的反制力已经真实地改变了博弈规则。

但对开源生态而言，真正的考题还没开始。承诺保持开源，不等于承诺中立：发行节奏是否被AWS的产品路线绑架、非AWS平台的兼容性是否降级、社区治理权是否稀释——这些都不会写在收购公告里。DuckDB能否在AWS体系内继续做「所有人的DuckDB」而非「Aurora的DuckDB」，需要用未来一两个发布周期来验证。

结语：底座之战，从此只有一个名字

先看数据：这笔交易的基本盘

在给出判断之前，先把可核实的关键数字摆在桌面上。下表区分了「公开可查的事实」与「推测或估算」，请读者注意区分：

这组数字放在一起，交易的轮廓就很清楚了：一个没有外部资本压力、却受困于变现路径的明星开源项目（数百万周下载、零规模化收费），遇上一个年入千亿美元量级、急需巩固数据栈入口的云巨头（AWS年营收超千亿美元，数据库是其披露的核心增长引擎之一）——前者缺的正是后者最不缺的分发能力，这大概就是这笔交易在商业上能够成立的最简解释。

再看判断：图什么，值不值

回到开头的问题：亚马逊买DuckDB，到底图什么？

短期图的是Aurora PostgreSQL的库内分析能力，省掉一条ETL管道；中期图的是HTAP体验的制高点；长期图的是一件事——让「上云之后的数据栈」从Postgres开始，也到Postgres结束。当事务、分析、向量、AI负载全部长在同一个内核和它的扩展体系上，中间层的独立数据基础设施，生存空间会被一层层压薄。

需要坦率说明的是，上文关于「中低复杂度分析需求回流Aurora、冲击Snowflake入门盘」的推演，属于基于产品逻辑的推测性判断——DuckDB单机引擎的实际定位更接近「小数据集的极速分析」，与Snowflake、Databricks所服务的云上大规模分布式分析场景仍有数量级差距，两条产品线短期内更可能是分层互补而非正面替代。

对从业者而言，该盯的不是这笔未披露金额的收购的价格，而是三个可验证的信号：其一，未来一两个发布周期内，DuckDB的开源承诺兑现质量（非AWS平台的兼容性是否降级、社区治理权是否稀释）；其二，PostgreSQL 19及后续版本在库内分析方向上的官方动作；其三，Snowflake和Databricks在「防止数据不出湖仓」方向上的反制产品发布。底座之战没有悬念的时候，真正的看点全在边缘——下一个被Postgres生态吸纳的，会是哪块能力？

注：本文中收购条款、首个集成特性等信息来自AWS官方公告口径；收购金额、竞争影响推演等标注⚠️的内容为推测或估算，不构成投资与选型建议；DuckDB Star数与下载量为时点数据，请以实时统计为准。