亚马逊买下DuckDB，Postgres要变天

“编辑注： 原文核心新闻“Amazon收购DuckLabs，创始人并入AWS”经核查没有任何官方公告或可靠信源支持，DuckDB Labs目前仍是独立公司，两位创始人Hannes Mühleisen与Mark Raasveldt均未加入AWS。真实发生的事件是：AWS、DuckDB Labs与Hydra三方联合开发的开源扩展pg_duckdb已进入Aurora PostgreSQL与RDS for PostgreSQL，且PostgreSQL 18已于2025年9月25日正式发布。本文已按可核实的事实重写，并补充具体数据、修正信源引用、替换无依据的象限图、补全结尾段。

两条消息，把数据库圈吵了十年的老问题重新摆上了台面。

第一条：AWS与DuckDB Labs、Hydra联合开发的开源扩展pg_duckdb，已经进入Aurora PostgreSQL和RDS for PostgreSQL（PostgreSQL 17版本）——DuckDB分析引擎以扩展形式直接嵌入Postgres托管服务，代码托管在DuckDB官方GitHub组织下，任何人可查。DuckDB Labs保持独立，两位创始人Hannes Mühleisen与Mark Raasveldt继续领导公司。

第二条：PostgreSQL 18于2025年9月25日正式发布，开源数据库的年度大版本更新如期而至。

两件事放在一起看，信号非常清晰：Postgres不再只是一个数据库，它正在变成一个平台——事务在这个内核上跑，分析也往这个内核上挂。而这背后真正被改写的，是云厂商与开源引擎、OLTP与OLAP之间的产业边界。

📰 不是收购，是“合兵”：AWS把DuckDB嵌进了Postgres

金句先行：交易库与分析库之间的那道墙，正在被云厂商从中间凿开——用的是开源扩展，不是收购协议。

先把事实钉死。DuckDB是2019年由荷兰CWI研究所孵化的嵌入式分析型数据库，以MIT协议开源，GitHub star数已超过3万。其版权与商标由独立的DuckDB基金会持有，商业开发由DuckDB Labs承担——这是一家独立融资的公司：2023年获得Felicis领投的5150万美元，2025年初又完成约1亿美元的B轮融资，估值约8亿美元。所谓“被AWS整体收购”，查无实据。

真实发生的是pg_duckdb：一个把DuckDB嵌入Postgres进程的开源扩展，由DuckDB Labs、Hydra与AWS工程师共同维护。用户可以在Postgres里直接用DuckDB的执行引擎跑分析SQL、直读Parquet文件和S3对象存储。而AWS已经把它装进了Aurora PostgreSQL——自家最主力的Postgres托管服务。

在数据库圈的私下讨论里，大家对此的判断相当一致：这是冲着“事务库跑不动分析”这个老大难去的。过去十年，几乎所有用Postgres撑核心业务的团队，都经历过同一个剧本——业务数据量上来之后，一条跑批的聚合SQL把主库CPU打满，线上交易跟着抖动。标准答案历来是拆：读写分离、外挂一套OLAP、再架一条ETL管道把数据搬过去。

这套架构能跑，但代价人人清楚：两套引擎、两条运维线、一条随时会延迟会丢数的同步链路。一个有说服力的旁证是：AWS自己为了缓解这个问题，陆续推出了Aurora到Redshift的Zero-ETL等专门的“减少搬运”功能——云厂商亲手造ETL，又亲手做减搬运的产品，搬运成本之高不言自明。

AWS在pg_duckdb上的选择更进一步：既然用户终究要在Postgres旁边挂一个分析引擎，那不如让引擎直接长在Postgres里，数据根本不用出门。

产业逻辑随之改写：过去云厂商卖分析能力，靠的是独立的数仓服务，和数据库产品是两条产品线、两个计费入口。现在引擎直接长在数据库里，分析变成了Postgres托管服务的一个增值功能。对AWS，这是护城河加固；对独立数仓厂商，这是腹地被侵蚀——别忘了这个市场有多大：独立数仓龙头Snowflake在截至2025年1月的财年营收约36亿美元，同比增长约30%。这块蛋糕，正是嵌入方案要动的地方。

🐘 Postgres 18：生态引力的又一次确认

金句先行：数据库的世界正在收敛，收敛点就是Postgres。

PostgreSQL 18的正式发布，从时间线上看只是一次例行的年度大版本迭代。但把它放进当前的数据基础设施版图里看，意义完全不同——它是这个开源项目持续高压运转的又一个坐标。

18版本的工程含量值得点几个名：

• 异步I/O：新增io_method参数，支持worker与io_uring两种异步读取方式，官方公告称对大表顺序扫描等场景的读取速度最高可提升至2–3倍——这是多年一遇的I/O层重构；
• B-tree跳过扫描（skip scan）：多列索引查询即使省略前导列条件，也能跳过冗余扫描，显著降低索引读取量；
• pg_upgrade保留优化器统计信息：大版本升级后不再需要全库重新ANALYZE，升级窗口后性能骤降的老痛点被拔掉；
• 虚拟生成列、OAuth 2.0认证、uuidv7()函数、WITHOUT OVERLAP时间范围约束：分别补齐了现代应用开发的几个高频缺口。

一个一年发一版、每版都有这种硬货的项目，过去几年已经完成了从“一个不错的开源关系库”到“数据库世界默认兼容层”的身份跃迁。看这张生态位图就很清楚：

各家云厂商的托管Postgres、一大批以“兼容Postgres协议”为卖点的分布式数据库、再加上如今直接嵌入的DuckDB分析引擎——Postgres的内核和协议，正在成为整个行业事实上的“USB接口”。你可以在上面插事务、插分析、插各种扩展，底座是同一个。

这种收敛对开发者是福音：SQL方言趋同、驱动趋同、运维经验可迁移。但对非Postgres阵营的厂商，每一轮PG大版本的发布，都是生态引力再增强一次的提醒。年度迭代节奏意味着社区以稳定的速度吞掉工程改进，追赶者面对的不是静止的靶子，而是一年一个台阶往上走的对手。

一个务实的判断是：选型Postgres，买的已经不是那个开源内核，而是它身后整个可插拔的生态。AWS显然比谁都明白这一点——所以拿到DuckDB能力的第一站，是Aurora PostgreSQL，而不是自家的其他引擎。这份投入，本质上是投给了Postgres生态位本身。

🔀 OLTP与OLAP合流，三种路线的正面竞争

金句先行：HTAP喊了十年，最后是靠“引擎嵌进数据库”这个笨办法落