不用自研引擎，Snowflake 悄悄在用 DuckDB
alitrack约 5 分钟2025 年 6 月，Snowflake 收购了 Crunchy Data。大部分人关注的是 "Snowflake 要做 PostgreSQL 了"——但真正值得看的是收购附带的另一个东西：Crunchy Data 用 DuckDB 做了一整套分析引擎。
五个月后，Snowflake 把这个项目开源了，叫 pg_lake。
● ● ●
收购的是 PostgreSQL，买到的是 DuckDB
Crunchy Data 的核心产品是 PostgreSQL 托管服务（Crunchy Bridge）。但它在 2024 年初开始做一件事：把分析查询从 PostgreSQL 卸载到 DuckDB。
为什么要这么做？PostgreSQL 是行式存储，做 OLTP 很强，但跑聚合查询、大表扫描效率不高。DuckDB 是列式存储，专门为 OLAP 设计。两者组合就是"湖仓一体"的思路。
Crunchy 的方案分成三步走：
- 01Crunchy Bridge for Analytics
（2024 年中）：PostgreSQL 查询 Iceberg/Parquet 文件，DuckDB 在后端执行 - 02Crunchy Data Warehouse
（2024 年 11 月）：加上了原生 Iceberg 表支持，PostgreSQL 可以创建和管理 Iceberg 表 - 03pg_lake
（2025 年 11 月）：Snowflake 收购后开源，Apache 2.0 协议
第一步的时候，pg_lake 就已经在跑 DuckDB 了。Snowflake 买的不是代码，是一个已经在生产环境验证过的 DuckDB+PostgreSQL 融合方案。
● ● ●
pg_lake 架构：PostgreSQL 做门面，DuckDB 做计算
pg_lake 的架构很清晰：
pg_lake 架构
两个关键设计决策：
1. 独立进程而非嵌入
pg_duckdb（DuckDB 官方 PostgreSQL 扩展）是把 DuckDB 嵌入 PostgreSQL 进程。pg_lake 选择让 DuckDB 跑在独立进程（pgduck_server），通过 PostgreSQL wire protocol 通信。
这么做是为了避免 PostgreSQL 进程模型的问题——PostgreSQL 是 fork 模型，每个连接一个进程，如果把多线程的 DuckDB 嵌入进去，内存和线程管理会很麻烦。
2. PostgreSQL 自己当 Iceberg 编目（Catalog）
大多数 Iceberg 方案需要一个外部 catalog（如 Polaris、Glue、Unity Catalog）。pg_lake 直接把 catalog 实现在 PostgreSQL 内部。这意味着：
你不需要额外部署 catalog 服务 PostgreSQL 的事务机制保证 Iceberg 表操作的原子性 其他引擎可以通过 JDBC 连接到 PostgreSQL 读取 Iceberg 元数据
● ● ●
DuckDB 在 pg_lake 中做什么
从使用者的角度看，你只需要用标准 SQL 操作 PostgreSQL。但底层发生了什么：
-- 创建 Iceberg 表（元数据在 PG，数据在 S3） CREATE TABLE logs USING iceberg ( event_time timestamp, user_id bigint, action text ); -- 从远程 Parquet 文件启动 Iceberg 表 CREATE TABLE trips USING iceberg WITH (load_from = 'https://.../yellow_tripdata_2025-01.parquet'); -- 分析查询（自动路由到 DuckDB） SELECT date_trunc('day', event_time) AS day, count(*) FROM logs GROUP BY day;当执行分析查询时，pg_lake 把 SQL 翻译成 DuckDB 方言，通过 pgduck_server 执行。DuckDB 直接读取 S3 上的 Parquet 文件，利用列式存储、向量化执行、谓词下推做计算，然后把结果返回给 PostgreSQL。
pg_lake 还维护了一个 duckdb_pglake 扩展，给 DuckDB 补齐 PostgreSQL 特有的函数，使得 SQL 翻译更完整。
● ● ●
为什么 Snowflake 要做这个
Snowflake 的核心业务是卖数据仓库。pg_lake 让开源 PostgreSQL 能做 Iceberg 分析——这看起来是在给自己造竞争对手。
但 Snowflake 的算盘是：
- 01扩大 Iceberg 生态
：更多工具往 Iceberg 写数据 → 更多数据 Snowflake 能读 → Snowflake Catalog-Linked Database 更有价值 - 02PostgreSQL 是入口
：Snowflake 同时推出了 Snowflake Postgres（托管 PG 服务，内置 pg_lake），用 PG 做 OLTP + DuckDB 做 OLAP，数据最终可以同步到 Snowflake 数仓 - 03开源建标准
：pg_lake 开源后，Databricks 收购的 pg_mooncake 基本停滞（最后一次提交距今 3 个月，S3 支持标记为 WIP），pg_lake 成了这个赛道的事实标准
● ● ●
三家对比：谁在用 DuckDB 给 PostgreSQL 加速
| pg_lake | ||||
| pg_mooncake | ||||
| pg_duckdb |
pg_lake 和 pg_mooncake 代表了两种路线：
- pg_lake
：手动同步，但更稳定。PostgreSQL 自己管理 catalog，你控制何时把 heap 表数据搬到 Iceberg。 - pg_mooncake
：自动实时同步，但复杂度高。需要 Moonlink 进程抓 WAL，连外部 catalog，v0.2 至今未稳定。
pg_duckdb 是另一个东西——它让 PostgreSQL 能调用 DuckDB 执行分析查询，但没有 Iceberg 表管理和增量同步能力，更像是给 PG 加了个列式加速器。
● ● ●
DuckDB 正在成为分析引擎的 "标准件"
这个趋势不仅限于 Snowflake。
- MotherDuck
：DuckDB 的托管云服务，本身就是 DuckDB 商业化 - DuckLake
：DuckDB 官方的湖仓格式，可以直接在 PG 中通过 pg_duckdb 使用 - ParadeDB 的 pg_lakehouse
：另一个把 DuckDB 嵌入 PostgreSQL 的扩展 - Alibaba Cloud PolarDB
：MySQL 使用 DuckDB 作为存储引擎，通过 Binlog 同步
DuckDB 从 "SQLite for OLAP" 变成了被各大厂商嵌入的分析计算单元。Snowflake 选择它而不是自研，因为 DuckDB 已经足够好——列式存储、向量化执行、Iceberg 支持、零依赖嵌入——这些如果从零做起，需要至少几年的工程投入。
● ● ●
总结
Snowflake 用 DuckDB 的方式很务实：不是重新发明轮子，而是把最好的列式引擎嵌入到自己控制的 PostgreSQL 生态里。
pg_lake 的真正价值不是 "PostgreSQL 能查 Iceberg"——单这个能力 DuckDB 自己早就有了。而是 PostgreSQL 的事务语义 + DuckDB 的列式计算 + Iceberg 的开放格式三者在一个系统里无缝协作，用户只需要 CREATE TABLE ... USING iceberg 一行 SQL。
至于 DuckDB 本身？它正在成为数据库行业的 "标准零件"。不管你卖的是 Snowflake、Databricks 还是阿里云，最后都可能悄悄装上一颗 DuckDB。