DuckDB 调研：MIT 协议的”嵌入式 OLAP 神兽”，2026 年 Quack 协议让数据本地分析彻底告别 ETL

一个 MIT 协议 + 列式 + in-process 的分析数据库——直接 SELECT * FROM 'file.parquet'、SELECT * FROM 's3://...'、pip install duckdb 立即跑通；2026 年 5 月发布 Quack client-server 协议 + 7 月 1.5.5 + 6 月 1.4 LTS” 长周期支持版 ”——SQLite 在 OLAP 世界的镜像答案。

写在前面

数据分析的 ” 本地 ” 环节一直缺一个顺手的工具：

• SQLite：OLTP 行式，做 GROUP BY 慢得像老牛
• Pandas：单机内存式，超过 RAM 就 OOM
• 装个 PostgreSQL 又太重
• 用云数仓（Snowflake / BigQuery）又烧钱 + 网络往返

2019 年 CWI 阿姆斯特丹数学中心的两位研究员 Mark Raasveldt + Hannes Mühleisen 在 Hacker News 上扔出 DuckDB，标语是 “SQLite for analytics”——嵌入式、零运维、列式、向量化。6 年过去，DuckDB 已经成为 AI Agent 时代的 ” 本地数仓 ” 事实标准：

• 5K+ GitHub stars 的衍生项目：sqlmesh / Cube.js / Apache Superset / Soda Core / Lightdash 全部把 DuckDB 列为默认引擎
• MotherDuck（云 DuckDB）拿了几亿美元融资
• Hugging Face 用 DuckDB 做数据集查询
• Polars（Rust DataFrame）把 DuckDB 当 backend

2026 年两个重磅：1.4 LTS 长周期支持版（5 年支持）+ Quack client-server 协议（远程访问从零起步）。DuckDB 已经从 ” 单机玩具 ” 正式进入 ” 分布式生产可用 ” 阶段。

一、它解决什么问题

一句话卖点 ：嵌入式（in-process）列式分析数据库， 单文件 / 零运维 / MIT 协议 / Python/R/JS/Rust/Go/Java 全客户端——直接查 Parquet / CSV / JSON / S3 / Iceberg / Delta，省掉所有 ETL 中间层。

基本信息

关键信号 ：DuckDB Foundation + DuckDB Labs 双轨治理——基金会管核心开源（MIT），商业公司管企业服务 + MotherDuck 云。 这跟 sqlmesh 进 Linux Foundation / dbt 由 dbt Labs 单挑 是不同的治理模式。

二、5 大设计原则（DuckDB 自我定位）

官网列出 6 个核心价值（其实是 6 个字母拼 ”duckdb”）：

这是数据库产品里少见的 ” 亲开发者 ” 设计哲学——没有 server，没有 daemon，没有配置文件。

三、核心能力：让 DuckDB 替代 ETL 工具链的 6 件事

1. 直接查文件——告别 ETL

-- CSV 直接查
SELECT * FROM 'data.csv';

-- Parquet 直接查（带谓词下推）SELECT * FROM 'data/*.parquet' WHERE date >= '2026-01-01';

-- 远程 S3 / R2 / GCS 直接查（需要 httpfs 扩展）INSTALL httpfs; LOAD httpfs;
SELECT * FROM 's3://my-bucket/events.parquet';

-- JSON 直接查
SELECT * FROM 'https://api.example.com/data.json';

这是 DuckDB 的杀手锏 ： 所有数据源 = 一张表。不需要先 COPY INTO、不需要 ETL pipeline、不需要建中间表。OLAP 工作流从 ” 抽取 → 转换 → 加载 → 查询 ” 压缩成 ” 查询 ”。

2. 友好的 SQL 方言——GROUP BY ALL / SELECT * EXCLUDE

DuckDB SQL 比 PostgreSQL 更友好，很多 ” 标准 SQL 不允许的语法糖 ” 它都支持：

-- 不用列举 group by 所有非聚合列
SELECT category, region, count(*) AS n
FROM events
GROUP BY ALL;

-- 加列时不用改 SQL
SELECT * EXCLUDE (ip, user_agent) FROM events;

-- 替换值
SELECT * REPLACE (price * 1.1 AS price) FROM products;

-- 命名窗口
SELECT *, avg(amount) OVER w FROM orders
WINDOW w AS (PARTITION BY customer_id ORDER BY date);

社区公认：DuckDB 是 ” 工程师友好度 ” 最高的 SQL 方言之一——写起来像 Pandas 那样顺手，但跑起来是真 SQL 引擎。

3. 列式 + 向量化 + SIMD——单机 10GB 数据秒级

DuckDB 是 向量化列式执行引擎：

• 数据按列存（Parquet 友好）
• 一批 1024-2048 行一起处理（向量化）
• SIMD 指令加速 filter/aggregate
• 多核并行（自动用满所有 CPU）
• 内存不够自动 spill 到磁盘

对比 SQLite（行式 OLTP）：同样 1GB CSV 做 GROUP BY，DuckDB 比 SQLite 快 100-1000 倍。

对比 Pandas：超过 RAM 时 Pandas 直接 OOM，DuckDB 自动 spill 到磁盘继续跑。

4. 6 大生态集成

生态信号：Apache Iceberg 写入支持（1.4 LTS）——DuckDB 不再只是 ” 读湖仓 ”，而是能写湖仓。Cube.js 用 DuckDB 做语义层引擎就是这个原因。

5. 5 大语言客户端 + WASM

duckdb-wasm 是杀手级特性——前端代码里直接执行 SQL 查 Parquet。Cube.js / Observable / DataCamp 都用这个。

6. Quack client-server 协议（2026-05 新发布）

长期以来 DuckDB 是 ”in-process”——必须跟应用同一进程。2026-05-12 发布 Quack protocol，让 DuckDB 可以走 client-server 模式：

• 客户端 / 服务端用 Quack 二进制协议通信
• 远程数据源（Postgres / S3 / Iceberg）可以集中缓存
• 远程共享同一 DuckDB 实例的资源

重要意义 ：DuckDB 正式进入分布式生产场景——不再是单机玩具。

四、DuckLake 1.0 + 湖仓格式（2026 生态）

2026-04 DuckDB 团队推出 DuckLake 1.0——一个 ” 基于 SQL 的湖仓格式 ”：

• 数据存 Parquet（不变）
• 元数据存 SQL 数据库（Postgres / MySQL / DuckDB itself）
• 替代 Iceberg / Delta 的 ” 自建 ” 路径——更简单、更 SQL-native
• 比 Iceberg 学习曲线低 10 倍

加上 1.4 LTS 加的 Iceberg 写入 + Delta Lake 写入，DuckDB 已经在湖仓格式上全栈布局： 读、写、改自家格式 DuckLake、读改 Iceberg、读改 Delta。

五、对比：DuckDB vs SQLite vs ClickHouse vs Pandas

核心判断：

• 10GB 以内的本地分析：DuckDB 是最优解——比 Pandas 强（不 OOM）、比 ClickHouse 简单（无 server）、比 SQLite 快（列式）
• TB 级 + 多用户 + 高并发：ClickHouse / Snowflake / Databricks 仍是主场
• AI Agent / Notebook / 嵌入式分析：DuckDB 已经事实上成为标准

六、实战：3 步跑通 DuckDB

# 1. 装（Python 客户端，5 秒跑通）pip install duckdb

# 2. 直接查 Parquet 文件（无 ETL）python -c "
import duckdb
duckdb.sql(\"SELECT category, count(*) AS n
            FROM 'events.parquet'
            WHERE date >= '2026-01-01'
            GROUP BY ALL
            ORDER BY n DESC\")
"

# 3. 持久化数据库 + 远程 Iceberg
duckdb my.db
INSTALL httpfs; LOAD httpfs;
INSTALL iceberg; LOAD iceberg;
CREATE TABLE iceberg_catalog.events AS
  SELECT * FROM 's3://my-bucket/events/*.parquet';

跑通后你能：
–
duckdb -c "SELECT ..." 命令行执行
– 浏览器打开 shell.duckdb.org 在线玩
– Jupyter / Marimo / Observable 里直接
import duckdb

七、DuckDB 生态：基金会 + Labs + MotherDuck

生态关系：
– 核心引擎 MIT → 永久开源
– DuckDB Labs 不控制版权（创始人版权已捐给 CWI / 基金会）
– MotherDuck 是
独立的商业云服务，跟 Labs 有合作但不从属

治理对比：
–
sqlmesh：进 Linux Foundation（基金会治理）
–
DuckDB：自建 DuckDB Foundation（小基金会治理）
–
dbt-core：dbt Labs 单公司控制
–
ClickHouse：ClickHouse Inc 单公司控制

八、风险与坑

1. 不是 OLTP：DuckDB 故意不做 OLTP，别拿它当 PostgreSQL 替代品——并发写入、高频 INSERT/UPDATE 都不行
2. 单进程：1.4 LTS + Quack 协议刚开始远程化，生产部署建议盯版本
3. 大数据上云：超过 100GB 数据建议 ClickHouse / Snowflake / Databricks
4. 并发限制：in-process 架构，多客户端并发受限于单进程吞吐
5. Iceberg 写入是新功能（1.4 LTS 才加），生产用先做 POC
6. DuckLake 是新格式（4 月才 1.0），生态成熟需要 1-2 年
7. 不替代数据仓库：DuckDB 是 OLAP 引擎，不是 ” 完整数仓 ”——没调度、没 catalog、没 lineage
8. WebAssembly 性能：浏览器里跑 DuckDB 大数据集（>100MB）会卡

九、总结

3 个最值得用的理由：

1. MIT + 嵌入式 + 列式 + 5 秒跑通：本地 OLAP 最优解，单文件数据库哲学
2. 文件直查 + 6 大客户端 + WASM：告别 ETL 中间层，AI Agent 时代的 ” 数据瑞士军刀 ”
3. DuckLake + Quack + 1.4 LTS：2026 年密集发布，开始从 ” 单机玩具 ” 升级到 ” 分布式生产 ”

一句话建议：

任何 10GB 以内的本地分析、AI Notebook、嵌入式 BI、原型验证 ——直接用 DuckDB， 别再装 PostgreSQL + Pandas + 5 个 ETL 工具 。它 就是 2026 年数据工程师的 ”SQLite for Analytics”。

参考

1. duckdb/duckdb · GitHub — 主仓库，MIT 协议
2. DuckDB 官网 — 设计原则 + 文档
3. DuckDB Foundation — 治理方
4. MotherDuck — 云 DuckDB（serverless 数据仓库）
5. DuckDB 1.4 LTS 发布说明 — 文件加密 + Iceberg 写入 + FILL 函数
6. Quack Client-Server Protocol — 2026-05-12 发布
7. DuckLake 1.0 — SQL 原生湖仓格式
8. DuckDB Engineering Blog — 官方更新日志（1.5.5 / 1.4.5 LTS 等）
9. DuckCon #7 Amsterdam — 2026 社区大会
10. MIT License — 协议全文