DuckDB：把分析型数据库塞进进程里，为什么 2026 年成了数据工程的默认件

DuckDB 是一个跑在宿主进程里的分析型（OLAP）SQL 数据库：像 SQLite 一样免安装、免运维、单文件存储，但为复杂分析查询而生——列式存储加向量化执行，一条 SQL 可以直接扫本地 CSV、Parquet、远端 S3，乃至 Iceberg 与 DuckLake 湖仓。它的上升曲线在基础软件里少见：GitHub star 从 2025 年 6 月的 30k 涨到 2026 年 8 月的 40k，截至 2026-10-10 达到 42.1k；PyPI 月下载超 5000 万，较上一次公开数据翻倍。2026 年它还经历两件大事：v2.0 完成特性冻结、预计 10 月下半年发布；母公司 DuckLabs 于 8 月底并入 AWS，项目以 MIT 许可留在 DuckDB 基金会。如果你常年在 pandas 与「先架个数仓」之间二选一，DuckDB 就是第三个选项。

DuckDB 是什么：嵌进进程里的分析引擎

先厘清定位。DuckDB 官方「为什么是 DuckDB」的表述是：它不像传统数据库那样作为独立进程运行，而是完全嵌入宿主进程——没有要装、要升级、要运维的数据库服务器，没有外部依赖，和 SQLite 的部署模型一致。区别在负载类型：SQLite 面向 OLTP（大量小事务、行级读写），DuckDB 面向 OLAP（复杂、长时间、大范围扫描的聚合查询），核心是一套列式向量化查询引擎——不是一行一行处理，而是一批一批值在 CPU 缓存里过，这是它分析性能的来源。

它是完整的数据库管理系统：SQL 支持 ACID 事务保证（MVCC 实现）、窗口函数、复杂关联子查询、数组结构体映射等复杂类型；数据落在单个数据库文件里，也可以不落盘、直接查外部数据。这个「进程内 + 单文件 + 全 SQL」的组合，让它能出现在意想不到的位置：笔记本上、浏览器（Wasm 构建）里、Hugging Face 上（2026 年 9 月刚更新了集成）、乃至 Spotify 的听歌历史 SQL 查询层（基金会 2026 年 8 月的社区案例）。

flowchart TB
  subgraph host["宿主进程：Python / R / Node / Wasm"]
    APP["应用代码"] --> ENG["DuckDB 列式引擎"]
  end
  ENG --> DB[("本地单文件库 .duckdb")]
  ENG --> FILE["Parquet / CSV：本地或 S3"]
  ENG --> LK["DuckLake：SQL 目录 + 对象存储"]

版本节奏也值得注意：从 2025 年的 1.4.0 开始，DuckDB 实行隔代 LTS——1.4 是首个长期支持版（社区支持一年，1.4.5 于 2026-06-17 发布），1.5 是常规版（当前 1.5.6，2026-09-28），2.0 在路上。对一个「嵌入式」数据库来说，这意味着生产环境终于有了明确的升级与支持节奏。

小结：DuckDB 的定位可以一句话说清——SQLite 的部署体验，加上列式 OLAP 的引擎，再接上整个数据湖生态。

它解决什么问题：分析查询不必先架一台服务器

DuckDB 回答的问题很多工程师都遇到过：数据在一个到几十个 GB 之间，想聚合、关联、透视一下，pandas 写着费劲还爆内存，上 Spark 或云数仓又太重。传统路径要求你先架一个数据库服务器（PostgreSQL 不适合列扫、ClickHouse 要运维），或者接受 dataframe 的内存与表达力上限。

DuckDB 的解法分三步。第一，零部署：进程内嵌入，Python 里 import duckdb 就有了一个分析引擎，没有连接管理、没有用户权限、没有端口。第二，数据不动：CSV、Parquet、JSON 直接当表查，S3 上的远端文件也能直接扫——数据不需要先「导入」再「查询」，临时分析的成本几乎归零。第三，单机够用到底：官方在 2025 年 10 月的基准文里展示过 TPC-H 10 万 GB 规模（约 100 TB CSV）的分析：22 条查询全部跑完，落库为约 27 TB 的单个数据库文件，在 1.5 TB 内存、192 核的 EC2 实例上中位耗时 1.19 小时，部分查询向磁盘溢写约 7 TB。这个数字的含义是：单机 DuckDB 的分析能力上限远高于大多数团队的日常需求。

性能的第三方佐证同样有分量：ClickBench 榜单上，DuckDB 内存模式在 2025 年 10 月曾冲到综合第一；规则调整（内存型数据库不再计入冷跑成绩）后，它仍是「热跑」里最强的开源系统，仅次于闭源研究原型 Umbra。这也是 DuckDB 官方 1.4 LTS 基准文给出的表述。

小结：DuckDB 把「分析这件事的启动成本」压到接近零——省掉的不是一个软件的安装时间，而是整条「搭环境、导数据、写 ETL」的路径。

技术亮点：列式向量化、单文件与「万物皆可查」

列式向量化执行引擎是第一亮点。按列组织数据、以向量（一批值）为单位执行算子，CPU 缓存命中率和 SIMD 利用率都远高于行式逐行处理，配合 zone maps 这类元数据剪枝，扫描还能跳过无关数据块。1.5.3 把 jemalloc 收进核心、2.0 进一步扩展异步 I/O——官方给出的递归 CTE 图查询基准从 4.90 秒降到 0.12 秒（约 40 倍），异步 I/O 则让网络存储（S3 上的 Parquet、CSV）上的查询显著提速。

单文件持久化 + 湖仓直连是第二亮点。.duckdb 单文件自带 MVCC 与 WAL，1.4.0 LTS 起还支持 AES-256-GCM 整库加密（库文件、WAL、临时文件全覆盖）；而查询侧不设边界——CSV、Parquet、JSON、Postgres、MySQL、Excel、ODBC 数据源都有官方扩展，Iceberg 支持读写（1.4 起可写），自家的 DuckLake 则把「湖仓」重新定义了一遍：元数据不放对象存储里堆小文件，而是放一个普通的 SQL 目录（SQLite、PostgreSQL、DuckDB 都能当），数据文件照旧在对象存储。DuckLake 2026 年 4 月发布 v1.0、规格承诺向后兼容，数据内联默认开启（小写入直接进目录库，绕开小文件问题），官方称之为「生产就绪」的 SQL-as-a-lakehouse 格式。

v2.0 的方向则回答了它最大的两个短板（都是相对服务器型数据库而言）。其一是网络能力：quack 扩展转正为 1.0，任何 DuckDB 实例可以作为服务端对外提供数据库，配套新的 CONNECT 语句，还有把 SQL 下推到 PostgreSQL/MySQL 的远程下推优化器——客户端/服务器形态第一次成为一等公民。其二是工程成熟度：全新 PEG 解析器（1.5 可选开启、2.0 默认，报错与建议大幅改善，扩展可以挂载语法）、稳定版本化的 C API（扩展「编译一次、随处签名托管」）、原生时区/排序规则（ICU 扩展内置化，微基准提速 2.2 到 2.6 倍）、VARIANT 半结构化类型（官方称为「增强版 JSON」）、完整触发器支持、NEAREST 相似度检索 JOIN。官方预告 v2.0.0 在 2026 年 10 月下半年发布，特性已冻结、alpha 构建可测。

小结：DuckDB 的技术叙事很完整——引擎层面持续榨单机性能，边界层面从「查本地文件」长到「查整个湖仓」，形态层面从嵌入式长出客户端/服务器能力。

2026 年现状：采用曲线与两件大事

采用数据（以下均截至 2026-10-10 或注明时点）：

• 体量：GitHub 42.1k stars、3.9k forks、8.7 万余次提交；官方 2026-08-05 的 40k star 致谢文给出 PyPI 月下载超 5000 万（此前公开口径为 2000 万）、官网月独立访客超 800 万、扩展下载流量超 2 PB。
• 开发者口碑：Stack Overflow 2025 年度调查显示 DuckDB 使用率从 2024 年的 1.4% 涨到 3.3%，数据库榜排第 4，与 SQLite 差距仅 0.2 个百分点；2024 年调研里它已位列「最受仰慕数据库」前三。
• 企业渗透：官方按 issue 提交者的公司归属估算，超过 20 家财富 100 强公司在用。
• 成本侧反馈：有数据团队公开报告，把合适的工作负载从常驻数仓挪到 DuckDB 后成本降了 80% 到 90%（ghostinthedata.info，2026-01）——单一口径不能外推，但方向与「免常驻基础设施」的定位自洽。
• 发版与维护：1.4 LTS 线维护至 2026 年 9 月，1.5 线月度级补丁（1.5.6 于 9 月 28 日），2.0 特性冻结、alpha 公测——节奏稳定得不像一个研究色彩浓厚的项目。

第一件大事是 DuckLabs 并入 AWS（2026-08-26 官宣，9 月初生效）。两位创始人 Mark Raasveldt 与 Hannes Mühleisen 的公司 DuckLabs 成为 AWS 子公司；公告同时明确：DuckDB、DuckLake、quack 及相关扩展保持 MIT 开源，知识产权仍在非营利的 DuckDB 基金会，路线图与治理模式不变，并将成立利益相关方咨询委员会。先立规矩再谈归属，这个顺序值得肯定；但「AWS 子公司 + 社区基金会」的长期张力值得观察——毕竟同一个云厂商既养它、也卖它的竞品（Athena、Redshift）。

第二件大事是 v2.0。这是近万次提交的大版本（1.5 发布以来 10000+ commits），换了解析器、换了默认存储格式、重做了 C API，官方明说会有一小批「精心挑选的破坏性变更」（旧库文件需迁移到存储 v2.0、lambda 箭头语法默认停用等）。版本号从 1 跳到 2 不是仪式感，是一次真正的引擎换代。

小结：2026 年的 DuckDB 完成了从「网红数据库」到「基础设施」的身份转换——采用数据、支持节奏、治理安排三件事都落了地。

与既有方案的对比

方案	形态	负载类型	典型规模	分工一句话
DuckDB	进程内嵌入	OLAP 列式	单机 GB 到 TB 级	本地/湖仓分析零部署
SQLite	进程内嵌入	OLTP 行式	单机应用内嵌	应用内小事务与点查
ClickHouse	服务器集群	OLAP 列式	分布式 PB 级	常驻服务化实时分析
pandas	进程内库	单机内存计算	内存量级	Python 生态的数据加工 API
Spark	集群框架	分布式批处理	集群 TB 到 PB 级	跨机器的大规模 ETL

几个常被问到的边界：对 SQLite，两者是嵌入世界的「一对分工」——事务型找 SQLite、分析型找 DuckDB，官方测试套件甚至直接复用了 SQLite 的用例。对 ClickHouse，关键差异是常驻服务 vs 嵌入：多客户端并发写、高可用、水平扩展是 ClickHouse 的主场，DuckDB 单机优先。对 pandas，DuckDB 官方 Python 包能直接在 DataFrame 上跑 SQL（零拷贝），不少团队的经验是「pandas 做特征加工、DuckDB 做聚合查询」混用而非替换。对 Spark，百 GB 以下单机跑得动的活，先试试 DuckDB 再考虑开集群。

独立基准的方向一致：复办的 H2O.ai database-like operations 基准里 DuckDB 位列头部（官方复盘文，2023-04）；MotherDuck 2023 年的三方对比里 DuckDB 最快、pandas 在较大负载上直接跑不完；GitHub 上可复现的独立对比给出 pandas 慢约 5 倍的量级。顺带把竞争关系说清：Polars 是 dataframe 赛道最认真的对手，内存效率与多线程都不弱，在上述多方对比中常排第二；两者 API 哲学不同（SQL 对 dataframe），负载大量重叠，选型时值得都跑一遍自己的场景。

小结：DuckDB 不是要取代谁，而是把「单机分析」这个此前没有专业工具的生态位补齐了。

上手十分钟：从安装到第一条分析查询

安装一行命令（macOS 与 Linux；Windows 有 winget 与安装脚本）：

curl https://install.duckdb.org | bash

语言客户端按需选：pip install duckdb（Python）、npm install @duckdb/node-api（Node.js）、Maven 坐标 org.duckdb:duckdb_jdbc:1.5.6.0（Java，截至 2026-10-10 的 1.5.6 版本号）。

CLI 下最惊艳的永远是第一步——CSV 直接当表查：

SELECT COUNT(*), AVG(amount)
FROM read_csv_auto('sales-2026.csv')
WHERE region = 'APAC';

Parquet 同理，远端也行：

SELECT date_trunc('day', ts) AS day, COUNT(*) AS hits
FROM read_parquet('s3://bucket/logs/2026-09/*.parquet')
GROUP BY day ORDER BY day;

Python 里嵌入使用，DataFrame 与 SQL 双向互通：

import duckdb

con = duckdb.connect("analytics.duckdb")
con.sql("""
    CREATE TABLE IF NOT EXISTS events AS
    SELECT * FROM read_parquet('events.parquet')
""")
print(con.sql("SELECT COUNT(*) FROM events").fetchall())

要试 2.0 的 alpha，官方给的方式是把安装脚本的环境变量切到 alpha 通道（curl https://install.duckdb.org | DUCKDB_VERSION=alpha bash），Python 端 pip install duckdb --pre --upgrade；官方明确提醒 alpha 仅供测试、勿上生产。想进一步了解湖仓形态，装 ducklake 扩展后可以用 PostgreSQL 当目录建一个 DuckLake 库。

小结：DuckDB 的上手成本几乎只有「会 SQL」这一条——数据在哪都行，先查起来再说。

短板与适用边界

把短板说透，选型才站得住：

• 不是 OLTP 数据库。单进程读写、多进程只读——DuckDB 用文件锁保证同一数据库文件同一时刻只有一个进程可写，这是嵌入式设计的直接代价，官方仓库里「Feature or Bug? Overcoming the single write connection」讨论串就是这类摩擦的典型样本。高并发写入的在线服务，请回到 PostgreSQL 或服务器型数据库。多写端诉求官方给的路线是 quack（客户端/服务器协议，2.0 转正）与 DuckLake（PostgreSQL 目录下实现并发读写），都还新。Rill Data 那篇标题即观点的分析说得直白——不做分布式是刻意的战略选择，也意味着它大概率永远不会是你集群里的那层数据库。
• 内存与磁盘的工程约束。分析查询内存吃得多，超出会溢写磁盘，代价是明显变慢；网络盘与共享文件系统上的文件锁不可靠，官方文档明确提醒要谨慎。
• 存储格式的历史包袱。旧版本 DuckDB 读不了新存储格式的库文件，跨版本共享 .duckdb 文件要约定格式版本；2.0 又将引入新的默认存储格式，升级策略要提前想好（官方预告 v2.0.0 于 2026 年 10 月下半年发布）。
• 扩展供应链仍在收紧中。官方扩展仓库历史上有过信任面争议，2.0 带来签名扩展与可自托管的可信仓库，才算把这一课补上。
• 治理的中立性问题。并入 AWS 后项目治理靠基金会与咨询委员会平衡，多云用户会不会有顾虑，时间会给答案。

小结：DuckDB 的边界非常清晰——单机分析、嵌入形态、读多写少；越界使用（OLTP、多写并发、分布式）才是事故的来源。

参考资料

• GitHub - duckdb/duckdb：仓库现状，star 数与默认分支（v2.0-cyanoptera）截至 2026-10-10。
• Thank You for 40 000 Stars on GitHub — DuckDB：PyPI 月下载、官网访客与社区案例的官方口径。
• A Preview of DuckDB v2.0 — DuckDB：v2.0 十大变更与发布时间窗。
• DuckLabs to Join AWS, Projects to Remain Open Source — DuckDB：收购公告与开源、基金会承诺原文。
• Adoption Metrics and Benchmark Results for DuckDB v1.4 LTS — DuckDB：采用指标、ClickBench 与 TPC-H 10 万 GB 基准。
• DuckLake v1.0 — ducklake.select：SQL 湖仓格式生产就绪公告。
• DuckDB 并发模型文档：单写者约束与多进程访问的官方说明。
• The Return of the H2O.ai Database-like Ops Benchmark — DuckDB：独立基准复盘，DuckDB 在 dataframe 类负载中位列头部。