AWS 收购 DuckDB 背后的公司，这把火烧到了 PostgreSQL

关注

原创 2026-08-28 18:59:22 379 阅读 AI 写同款· GEO 优化 ›

DuckDB与PostgreSQL的无缝融合：pg_duckdb如何简化混合数据分析工作流本文详细介绍了pg_duckdb如何实现DuckDB与PostgreSQL的无缝融合，简化混合数据分析工作流。通过双重执行机制和数据类型兼容性，pg_duckdb显著提升了OLAP查询性能，同时支持对象存储集成和数据导出功能。文章还提供了安装配置指南、性能优化技巧和实际应用案例，帮助开发者高效利用列矢量化分析引擎优化数据分析流程。阅读详情

一、AWS 买下的是公司，不是 DuckDB

就在这周，AWS 宣布已签署最终协议，收购位于阿姆斯特丹的 DuckLabs——DuckDB 背后的公司。DuckLabs 团队将整体加入 AWS。 DuckDB 本身继续留在独立的非营利组织 DuckDB Foundation 名下，继续以 MIT 协议免费开源；DuckDB 的创造者、DuckLabs 联合创始人 Hannes Mühleisen 和 Mark Raasveldt 将继续带领团队，并继续主导开源项目的技术方向。

DuckDB 是一个进程内的列存分析型数据库，常被称作「分析领域的 SQLite」。它没有服务端，不需要独立部署，以库的形式被宿主程序链接进去。而正是这个形态，让它走出了一条和其他分析引擎都不同的路。

二、PostgreSQL 的 OLAP 短板，与 pg_duckdb 的诞生

先说问题

PostgreSQL 是典型的行存 OLTP 引擎，它在事务处理上非常强，但跑大规模聚合、全表扫描、大 JOIN 时，比不过列存向量化引擎——这不是实现好坏的问题，是存储布局和执行模型决定的。

长期以来这个缺口靠 ETL 填：把数据同步一份到外部数仓，交易归交易，报表归报表。这也意味着数据副本、同步延迟。

而 DuckDB 恰好是列存向量化引擎里最特别的一个：它是进程内的，以库的形式存在，没有服务端、不需要独立部署。一个不需要独立部署的分析引擎，天然就适合被塞进另一个数据库里。 这个想法并不难想到，难的是把它做出来。

pg_duckdb 项目起源

2024 年 8 月，一个把 DuckDB 嵌入 PostgreSQL 的开源协作项目公开亮相，参与方是三家：Hydra、DuckDB Labs、MotherDuck。项目最初由 Hydra 发起，他们此前一直在做 PostgreSQL 上的分析扩展，贡献了 PG 扩展与存储方面的工程经验；DuckDB Labs 提供引擎侧的支持；MotherDuck 则把它接进了自己的云服务。

三家凑到一起并不是巧合——它们面对的是同一个需求：Hydra 要给 PG 用户提供分析能力，MotherDuck 要让 DuckDB 能对接存量的 PG 数据，DuckDB Labs 需要一条通往 OLTP 世界的入口。各做各的，不如合做一个。

项目最终落在了 DuckDB 自己的 GitHub 组织下——github.com/duckdb/pg_duckdb。这就是「官方扩展」的实际含义：不是一个第三方项目被认可，而是它本身就归属在 DuckDB 组织内维护。

两个项目是什么关系

总结来说就是 DuckDB 是引擎，pg_duckdb 是引擎的外壳。

DuckDB 以 git submodule 的形式被引入（third_party/duckdb，指向 github.com/duckdb/duckdb.git），版本在 Makefile 里被钉死（DUCKDB_VERSION，随上游主线滚动升级），编译后与扩展代码一起链进同一个 .so。
运行时，DuckDB 与 PostgreSQL backend 同进程、同地址空间。没有网络、没有 IPC、没有独立进程，CREATE EXTENSION pg_duckdb 之后，每个 backend 内部就多了一个可用的分析引擎。
依赖方向是单向的：DuckDB 完全不知道 pg_duckdb 的存在，可以独立使用；pg_duckdb 离开 DuckDB 则无法存在。

分工也很清晰：事务、权限、catalog、存储、连接管理仍然全部归 PostgreSQL；DuckDB 只负责列存向量化执行。用户侧的开关很简单：

SET duckdb.force_execution = true;

之后不改一行 SQL，符合条件的查询就会走 DuckDB 执行；不支持的查询自动回退到 PostgreSQL 原生执行器。

三、pg_duckdb 是怎么实现的

理解 pg_duckdb 的实现，最关键的一点是：它不是把 PostgreSQL 的计划树翻译成 DuckDB 的计划树，而是把查询反解析成 SQL 文本，交给 DuckDB 重新解析。

这个「SQL 文本往返」是整个架构的核心，也是后面所有适配工作的根源。完整链路如下：

1. Hooks 拦截查询

_PG_init 时接管三个 hooks（src/pgduckdb_hooks.cpp）：planner_hook、ExecutorStart_hook、ExplainOneQuery_hook。查询进入规划阶段时先过一遍判定：是否开启了 force_execution、是否引用了 DuckDB 才有的表函数（read_parquet 等）、是否命中不支持的类型或语法。不合格就原样交还 standard_planner，用户全程无感知。

2. 反解析成 DuckDB SQL

命中之后，pgduckdb_planner.cpp 调用 pgduckdb_get_querydef()（src/pgduckdb_ruleutils.cpp，是 PostgreSQL pg_get_querydef 的定制版本），把 Query 树重新渲染成一段 SQL 字符串，再交给 DuckDB 的 Connection::Prepare()。DDL 路径类似，pgduckdb_get_tabledef() 负责把 PG 表定义渲染成 DuckDB 的 CREATE TABLE。

3. 用 CustomScan 节点承载执行

规划结果是一个 CustomScan 节点（src/pgduckdb_node.cpp），实现了 BeginCustomScan / ExecCustomScan / EndCustomScan / ExplainCustomScan 一整套回调。对 PostgreSQL 的执行器而言，DuckDB 只是一个普通的扫描节点：每次 ExecCustomScan 从 DuckDB 拉一批结果，转成 TupleTableSlot 往上吐。这也是 EXPLAIN 能同时展示两边计划的原因。

4. 反向读回 PostgreSQL 堆表

数据不需要导出。DuckDB 侧通过 replacement scan 机制注册了对 PG 表的访问（src/scan/postgres_scan.cpp、postgres_table_reader.cpp）：当 DuckDB 解析到一个它 catalog 里没有的表名时，回调进 pg_duckdb，由后者直接走 PostgreSQL 的缓冲区管理器和快照读堆表。过滤条件会被下推回 PG 侧扫描（ExtractQueryFilters），并且支持拉起 PostgreSQL 并行工作进程来喂数据。

5. 类型双向映射

src/pgduckdb_types.cpp 负责两个方向的转换：PG OID → DuckDB LogicalType，以及 DuckDB 值 → PG Datum。这是整个扩展里最琐碎也最容易出问题的一块——两边的类型系统并不同构（典型如无精度约束的 NUMERIC，默认会告警回退）。

另外还有 src/catalog/ 下的一组文件，让 DuckDB 的事务管理器与 PostgreSQL 的事务边界对齐；src/vendor/ 则是从 PostgreSQL 和 DuckDB 内部抄出来的头文件——这也说明了两个项目的耦合有多紧：DuckDB 的 C++ 内部 API 并不承诺稳定，每次升级 DuckDB 版本，pg_duckdb 往往都要跟着改代码。

四、IvorySQL 的工作：ivy_duckdb

IvorySQL 是基于 PostgreSQL 的 Oracle 兼容数据库，在内核里实现了一整套 Oracle 兼容的数据类型和语义。这些类型是 IvorySQL 自己注册的，OID 是动态分配的——而 pg_duckdb 的类型映射大量依赖硬编码的内建 OID 判断。直接拿上游 pg_duckdb 用在 Oracle 模式下，结果就是：要么大面积回退、失去加速，要么在类型转换路径上直接报错。

于是有了 ivy_duckdb（https://github.com/IvorySQL/ivy_duckdb ），IvorySQL 维护的 pg_duckdb 分支。当前基线是上游 pg_duckdb 1.1.0 + DuckDB v1.4.3，相对上游约 2500 行改动，集中在 src/、include/、test/ 三处。主要工作分成四块：

1. 动态 OID 的类型识别与缓存

新增 Ivory*Oid() 一族接口（include/pgduckdb/pgduckdb_metadata_cache.hpp），覆盖 IvorySQL 中实现的 Oracle 兼容类型，通过 catalog 查找拿到运行时 OID 并缓存起来，随 catalog 失效自动更新。类型映射的判据从「硬编码 OID」改成「查缓存」，这是所有后续工作的地基。

2. 兼容「SQL 文本往返」

alias 扩展。ivy 类型在 DuckDB 侧以 alias 形式承载（如 TIMESTAMP 带 alias ivory:oradate），PG 侧重新解析时在 postgres_scan.cpp 里做 alias 剥离后再渲染。
类型名规范化。反解析出的 oracle 类型名 DuckDB 不认识，需要在 pgduckdb_ruleutils.cpp 做文本改写 ,并通过 ExtensionLoader::RegisterType() 把全部 Oracle 兼容类型正式注册进 DuckDB 的系统 catalog。

3. 稳定性与工程化

增强使用体验，增加诊断扩展状态的系统函数。
支持离线构建（OFFLINE=1 关闭 httpfs 的 FetchContent 拉取，预安装 Duckdb 扩展），适配内网环境。

4. 开箱即用：ivy_mooncake 与 Docker 镜像

ivy_duckdb 本身是一个扩展，需要自行编译安装。对想快速上手的用户，更方便的入口是 **ivy_mooncake**（https://github.com/IvorySQL/ivy_mooncake ）——IvorySQL 维护的 pg_mooncake 发行版，它把 ivy_duckdb 直接作为子模块包含在内。

pg_mooncake 本身是给 PostgreSQL 表建立 Iceberg 列存镜像的扩展：行存表照常承担 OLTP 写入，镜像表以亚秒级新鲜度同步，分析查询打在列存上，加速引擎正是 DuckDB。它的扩展控制文件里写着 requires = 'pg_duckdb'——也就是说，ivy_mooncake 天然依赖 ivy_duckdb，两者是一套东西的两层：

ivy_duckdb —— 查询加速层。行存表不动，符合条件的查询交给 DuckDB 执行。
ivy_mooncake + ivy_moonlink —— 列存镜像层。通过逻辑复制把行存表增量同步成 Iceberg 列存，分析查询直接打列存。

最快的体验方式是预览镜像，里面已经预装并预加载好了 IvorySQL + pg_duckdb + pg_mooncake：

docker run --name ivy_mooncake \
  -e IVORYSQL_PASSWORD=password \
  -p 5432:5432 -p 1521:1521 \
  -v ivy_mooncake_data:/var/lib/ivorysql/data \
  -v ivy_mooncake_warehouse:/tmp/moonlink_iceberg \
  registry.highgo.com/mooncake/ivy_mooncake:0.1

起来之后三条语句就能看到效果：

CREATE EXTENSION pg_mooncake CASCADE;          -- CASCADE 会一并装上 pg_duckdb

-- 开启查询加速，然后查原表即可
SET duckdb.force_execution = true;

五、给 IvorySQL 带来的 OLAP 能力

把上面这些工作串起来看，结论其实很简单：IvorySQL 在保持 Oracle 兼容的前提下，获得了原生的 OLAP 分析能力。

TP 侧不变。行存表、事务、约束、Oracle 兼容的 PL/SQL 和数据类型，全部照旧，没有任何妥协。
OLAP 侧两档可选。轻量档是 ivy_duckdb 的查询加速：SET duckdb.force_execution = true，SQL 一行不改，直接吃到列存向量化执行；重量档是 ivy_mooncake 的 Iceberg 列存镜像：给热表建一个自动同步的列存副本，分析查询打在副本上，行存侧的 OLTP 负载不受影响。

两档能力的详细用法——列存镜像的建立与同步、加速路径的开关与回退规则、Oracle 类型的支持范围——参见 IvorySQL/ivy_mooncake (https://github.com/IvorySQL/ivy_mooncake) 仓库文档。

我们在 IvorySQL 的 Oracle 兼容模式和 pg 模式下都做了验证，用 TPC-H 查询集对三条执行路径做了同机横比：行存原生执行、ivy_duckdb 查询加速、ivy_mooncake 列存镜像。结论是清晰的量级差异——查询加速相对原生执行有明显提升，列存镜像则再上一个台阶，两者的差距在大数据量、重扫描的聚合类查询上尤其突出。

六、小结

回到开头：AWS 收购 DuckLabs，改变的是 DuckDB 的资源与商业化路径，没有改变它的许可证和治理结构。真正烧到 PostgreSQL 的，不是这桩交易本身，而是它背后那个已经成立的事实——列存分析引擎可以被装进 OLTP 数据库，而且已经有人跑通了。对 PostgreSQL 生态而言，更值得关注的是 pg_duckdb 这条已经跑通的路径：不改 SQL、不搬数据、同进程嵌入，把列存向量化能力直接补进 OLTP 数据库。

目前 ivy_mooncake/ivy_duckdb 发布的是 v0.1 预览版，欢迎大家使用。如果遇到问题，欢迎到仓库提 issue：

IvorySQL/ivy_mooncake (https://github.com/IvorySQL/ivy_mooncake)
IvorySQL/ivy_duckdb (https://github.com/IvorySQL/ivy_duckdb)

参考链接

duckdb/pg_duckdb — DuckDB 官方 PostgreSQL 扩展
IvorySQL/ivy_duckdb — IvorySQL 的 Oracle 兼容适配分支
IvorySQL/ivy_mooncake — 包含 ivy_duckdb 的列存分析发行版，提供 Docker 预览镜像
IvorySQL/ivy_moonlink — moonlink 的 IvorySQL 适配分支，Rust 实现的 Iceberg 实时摄取引擎，通过逻辑复制把行存表的增删改同步进列存镜像
AWS to acquire DuckLabs, the Amsterdam-based company behind DuckDB — AWS 官方公告
pg_duckdb: Splicing Duck and Elephant DNA — pg_duckdb 项目发起时的介绍