◈ DB 选型参考
← 返回首页

DuckDB

OLAP #嵌入式 #OLAP #单机 #列存 #向量化执行 #MIT开源 #Python生态 #零运维

"分析型 SQLite"——跑在进程里的单机列存 OLAP 引擎：pip install 即用、向量化执行吃满多核、直接对 Parquet/CSV/S3 做 SQL，把"不够上数仓、pandas 又太慢"的中间地带一口吃掉；代价是单写者、单机天花板，以及所有服务端能力（认证、审计、多用户）一概没有。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商DuckDB Labs（2026-05 更名为 DuckLabs，30+ 人）；2026-08-26 宣布加入 AWS，DuckDB/DuckLake/Quack 等开源项目仍归独立的 DuckDB Foundation 所有、保持 MIT 许可
国家荷兰（阿姆斯特丹；源自 CWI 国家数学与计算机科学研究中心）
起源2018 年 Hannes Mühleisen 与 Mark Raasveldt 在 CWI 启动；2019 年 SIGMOD 发布 v0.1；2024-06 发布 v1.0
许可证MIT（建项目第一天起即开源；DuckDB Foundation 持有大部分 IP）
托管服务MotherDuck（独立公司，serverless 托管 + 混合执行）；DuckLake（开放湖仓格式，v1.0 于 2026-04-13 发布）
主类型关系型（嵌入式、进程内 OLAP）
兼具类型数据湖查询（直接读 Parquet/Iceberg/Delta）、联邦查询（ATTACH 外部库）

硬维度（47 项）

1 静态加密 / TDE 有

有——v1.4.0 起支持透明加密：ATTACH 'f.db' AS d (ENCRYPTION_KEY '...')，AES-256-GCM（默认）/ AES-CTR-256，覆盖主文件、WAL 和溢出临时文件；密钥丢失则数据不可恢复，不支持原地加密/解密/轮换（需 COPY 到新库）；官方声明尚未达到 NIST 合规要求（跟踪 issue #20162）。证据：官方文档（1.4.0 发布公告、encryption 博客）。

2 TLS / 传输加密 不适用

不适用——进程内嵌入式，无服务端、无网络协议、无监听端口；httpfs 读 S3/HTTPS 是客户端 TLS；云端传输加密是 MotherDuck 托管服务的能力。证据：官方文档（架构）。

3 审计 不适用

不适用——无用户体系、无服务端审计日志；谁拿到文件谁就能读。审计需求由宿主应用自己实现。证据：官方文档（架构）+ 社区共识。

4 认证与权限 不适用

不适用——进程内嵌入式，无服务端/用户体系、无 GRANT 模型；文件系统权限即权限边界。证据：官方文档（架构）。

5 备份恢复 部分支持

部分支持——无在线备份工具、无 WAL 归档、无 PITR。可用方式：EXPORT DATABASE 'dir' (FORMAT PARQUET)（MVCC 一致快照，可在线，是社区推荐默认方式）、COPY FROM DATABASE 跨库拷贝、进程关闭后直接拷贝 .duckdb 文件；打开状态下直接 cp 文件可能损坏社区共识。恢复 = IMPORT DATABASE 或文件替换。证据：官方文档 + 社区共识。

6 可观测性 部分支持

部分支持——有：EXPLAIN / EXPLAIN ANALYZE、PRAGMA profiling（json 输出可画火焰图）、duckdb_memory()、pragma_database_size()、duckdb_temporary_files()、duckdb_settings()、duckdb_databases()；查证为无：慢查询日志、跨会话查询历史（duckdb_queries()/duckdb_connections() 不存在，社区探针 v1.5.5 实测确认）、PRAGMA integrity_check。证据：官方文档 + 社区实测。

7 连接模型 有

有——进程内连接，创建开销极低；查询自动用满全部 CPU 核心（SET threads 可调）；无网络往返、无连接池概念（不需要）。证据：官方文档 + 社区共识。

8 事务与隔离级别 有

有——ACID；为批量优化的 MVCC（借鉴 HyPer），默认快照隔离（Snapshot Isolation）；进程内多线程写走乐观并发：append 永不冲突，并发 update/delete 同一行后者报冲突失败；跨进程只允许"单进程读写"或"多进程只读"，第二进程写会报文件锁错误；无 SAVEPOINT社区共识。证据：官方文档（concurrency）+ 社区共识。

9 复制与一致性 不适用

不适用——单机进程内引擎，无复制协议、无多副本一致性；"多副本" = 文件拷贝；多机协作靠 DuckLake（对象存储 + 元数据）或 MotherDuck；Quack client-server 协议 2026-05 技术预览、beta 中。证据：官方文档 + 社区共识。

10 扩展方式 部分支持

部分支持——纵向扩展（scale-up）有：多核并行 + 外存溢出，单机吃到 GB~数百 GB；横向扩展（scale-out）查证为无：引擎本身不支持分布式查询，多机方案只有 MotherDuck 托管（serverless ducklings）或应用层分片。证据：官方文档 + 社区共识。

11 兼容性 部分支持

部分支持——SQL 方言对标 PostgreSQL（非 PG 线协议）；扩展可 ATTACH 外部库做联邦查询（postgres/sqlite/mysql 扫描扩展）；Python/R/Arrow/Polars/pandas 零拷贝集成；dbt 有社区适配器 dbt-duckdb；WASM 可跑浏览器。证据：官方文档 + 社区共识。

12 许可证与商业模式 有

有——MIT 全开源，无功能阉割的社区版；DuckDB Foundation（非营利）持有 IP；商业化 = DuckLabs（原 DuckDB Labs）支持/咨询服务 + MotherDuck 独立公司的 serverless 托管（按存储 GB 与计算秒计费，免费层 10GB——厂商口径）。2026-08-26 DuckLabs 宣布加入 AWS，开源项目治理与许可不变（官方口径）。证据：官方 history + AWS 官方博客。

13 中文资料丰富度 部分支持

部分支持——官方文档为英文；中文资料以博客、课程、知乎/CSDN 实践帖为主，体量远小于 MySQL/PG 及国产主流库；出海/英文生态反而是强项。证据：社区共识。

14 性能与延迟特征 有

有（嵌入式 OLAP 单机极快；无分布式）。

  • 进程内列存向量化执行，笔记本上 TB 级以下分析查询秒级社区共识社区共识。
  • 无分布式，并行上限为单机核数；超大内存需求靠溢出到磁盘 官方文档。
  • 读 Parquet/CSV 极快，是“单机数仓”的事实标准 社区共识。
  • 第三方印证：2026-10-01 AWS 官方博客宣布在 Aurora PostgreSQL 内嵌入 DuckDB（aurora_analytics 扩展）做 Iceberg/Parquet 分析扫描——"嵌入式分析引擎能被装进其他系统"论点的厂商级背书。但内嵌的 DuckDB 版本与功能裁剪情况未公开，尚无独立第三方性能对比：背书的是架构选择，不是性能数字 AWS 官方博客。

15 合规与认证 部分支持

部分支持（嵌入式无；MotherDuck 云服务有 SOC2）。

  • DuckDB 嵌入式库：无合规认证概念，合规责任在宿主应用 社区共识。
  • MotherDuck（云服务）：SOC2厂商口径厂商口径。

16 成熟度与社区生态 有

有（2018 年诞生；嵌入式 OLAP 的现象级项目）。

  • 2018 年由 CWI（荷兰数学与计算机中心）发布；DuckDB Labs/MotherDuck 商业化 社区共识。
  • GitHub stars 数万级，增长极快；基金会治理，中立性好 社区共识。
  • 年轻但口碑极佳，“SQLite for Analytics”定位深入人心 社区共识。

17 标杆用户 有

有（数据团队/个人开发者极广；企业级案例在积累）。

  • 个人开发者、数据团队几乎人手一个社区共识社区共识。
  • 被大量数据工具内嵌（dbt 等）社区共识。
  • 大型企业核心数仓案例少于 ClickHouse，MotherDuck 在积累 社区共识。

18 生态工具链 部分支持

部分支持（文件即备份；无 CDC 概念）。

  • 备份：文件拷贝即备份；MotherDuck 云同步/分享 官方文档。
  • 无 CDC/复制工具链（嵌入式定位）；与 pandas/Arrow/dbt 集成极好 社区共识。
  • 工具链薄是形态决定的 社区共识。

19 云托管与 Serverless 有

有（MotherDuck（Serverless 云））。

  • MotherDuck：DuckDB 的 Serverless 云服务，共享/协作 官方文档。
  • 嵌入式本质不变：云是可选增强，不是必需 社区共识。

20 数据接入与摄入 有

有（COPY FROM/Parquet 直读，单机摄入极简）。

  • COPY FROM 支持 CSV/Parquet/JSON；read_parquet/read_csv 可直接查文件不导入 官方文档。
  • 批量 INSERT 也快，单机分析场景摄入几乎零运维 社区共识。
  • 大文件注意内存与临时目录，可用流式读 社区共识。

21 外部数据访问 有

有（httpfs 直查对象存储；PG/MySQL scanner 扩展）。

  • httpfs 扩展可直接查询 S3/HTTP 上的 Parquet/CSV 官方文档。
  • postgres/mysql 扩展可把外部库表当本地表扫描 官方文档。
  • 嵌入式场景下这是它最被低估的能力之一 社区共识。

22 CDC 与下游同步 不适用

不适用（嵌入式无服务进程，无 CDC 语义）。

  • 单进程嵌入式引擎，无变更日志/复制槽概念 官方文档。
  • 数据同步靠重新导入文件或上层应用处理 社区共识。

23 TTL 与数据生命周期管理 无

无（嵌入式单机，无 TTL 机制）。

  • 无原生 TTL/分区过期，需应用层 WHERE 过滤或定期 DELETE 官方文档。
  • 定位是嵌入式分析引擎，数据生命周期由宿主应用管理 社区共识。
  • 大删后需 VACUUM/重写回收空间 社区共识。

24 在线 DDL 与 Schema 演进 不适用

不适用（嵌入式单机，无"在线 DDL"概念——schema 演进就是同一进程内对本地 catalog/文件执行的事务性 DDL，没有并发 DDL 阻塞或在线迁移窗口问题）。

  • 只改定义不碰数据：ADD/DROP/RENAME COLUMN、改列 COMMENT/DEFAULT 都是 catalog 层变更；官方文档未明确说明物理重写代价（未找到证据）。
  • 重写数据但位置不变：ALTER ... TYPE 按表达式转换存量数据（USING 子句或默认 cast），转换失败整个语句报错回滚 官方文档；列上有索引或 CHECK 约束依赖时先报依赖错误，需先删再建 官方文档。
  • 搬数据：无分区键/排序键概念；大结构调整（换列顺序等）走 CREATE OR REPLACE TABLE AS 重建 官方文档。
  • 验证约束：PRIMARY KEY/UNIQUE/NOT NULL/CHECK 支持（ADD PRIMARY KEY 自 v1.2，多列自 v1.5）官方文档；ADD/DROP CONSTRAINT 不支持 官方文档；FOREIGN KEY 语法存在但默认不强制 社区共识。
    • 规模：代价取决于单机文件/数据量；改类型需转换全列数据，官方文档未给出代价模型（未找到证据）。
    • 语义：ALTER 完全遵守事务语义——未提交对其他事务不可见、可回滚 官方文档；单写者模型，无并发 DDL 概念 社区共识。

25 多租户与资源隔离 不适用

不适用（嵌入式单进程，无多租户场景）。

  • 嵌入式单进程，资源隔离无意义 官方文档。
  • 单库单用户是典型用法，多租户请用服务端数据库 社区共识。

26 跨地域多活 不适用

不适用（嵌入式单机，无地域概念）。

  • 单进程嵌入式，多活无意义 官方文档。
  • 文件级复制可做异地备份，但不是多活语义 社区共识。

27 高可用架构与 RTO/RPO 不适用

不适用（嵌入式单机，无 HA 语义）。

  • 单进程嵌入式，HA 靠宿主应用/文件备份 官方文档。
  • 进程崩溃靠宿主重启，单文件数据易备份 社区共识。

28 行级安全与数据脱敏 无

无（嵌入式分析库，无访问控制）。

  • DuckDB 是嵌入式 OLAP 库，无用户 / 权限体系，原生无 RLS、列级权限与脱敏 官方文档
  • 安全完全依赖宿主应用：文件权限、应用层过滤 社区共识
  • 脱敏靠 SQL 视图或查询改写 社区共识

29 JSON 与半结构化能力 有

有（JSON 扩展，自动推断）。

  • JSON 扩展，JSON 类型，->> 提取，自动 schema 推断 官方文档。
  • 嵌入式分析定位，超大半结构化文件注意内存 社区共识。

30 全文检索能力 部分支持

部分支持（FTS 扩展尚实验性）。

  • 官方 FTS 扩展提供全文检索，尚实验性 官方文档。
  • 生产关键词检索多靠 LIKE/正则或前置处理 社区共识。

31 存储效率与压缩 有

有（列存+轻量编码自动压缩）。

  • 列式存储格式，对每列自动选择轻量压缩编码（RLE、字典、位-packed、FSST 等）。官方文档
  • 压缩为默认自动行为，无需配置，Parquet 读写同样高效。官方文档
  • 嵌入式场景下压缩比表现优秀，是其单文件分析的核心优势之一。社区实测

32 开源协议与厂商锁定风险 无

无（MIT 开源；嵌入式无锁定）。

  • DuckDB 采用 MIT 协议开源，是最宽松的主流开源协议之一。官方文档
  • 嵌入式进程内数据库，无服务端、无云绑定，从设计上不存在厂商锁定。社区共识
  • 无协议变更黑历史，基金会治理模式清晰。社区共识

33 查询优化器与计划稳定性 有

有（向量化 CBO；自动优化好，无 hint）。

  • 向量化执行 + CBO，EXPLAIN 完备，小查询优化出色 官方文档。
  • 无 hint 机制，计划干预手段少 官方文档。
  • 嵌入式场景计划翻转风险低 社区共识。

34 参数调优与自治能力 有

有（零配置自治：PRAGMA 少量参数）。

  • 开箱即用，PRAGMA 参数少且有合理默认 官方文档。
  • 内存/线程自动感知，自治程度在嵌入式库中突出 社区共识。

35 静默数据损坏防护 未找到证据

未找到证据（未见公开的页校验或损坏自愈机制）。

  • 未找到官方文档描述页 checksum、损坏检测或自愈流程。待验证
  • 作为嵌入式 OLAP 引擎，文件损坏多靠上层应用或备份策略兜底。社区共识

36 存储过程/触发器/过程语言 无

无（查证为无存储过程/触发器）。

  • 无存储过程、触发器（查证为无）官方文档。
  • 逻辑在宿主语言（Python/R）中 社区共识。

37 约束与数据完整性 有

有（单机主键/外键/CHECK 完整）。

  • 主键、外键、CHECK、唯一约束完整（单机）官方文档。
  • 分析场景常关闭约束以提速，约束主要起语义作用 社区共识。

38 分析 SQL 完备性 有

有（分析 SQL 强项，窗口完备）。

  • 窗口函数、CTE、PIVOT 等分析 SQL 为强项 官方文档。
  • 单机内存/磁盘上限是天花板 社区共识。

39 被遗忘权与数据擦除 部分支持

部分支持（DELETE即删；文件残留靠VACUUM）。

  • DELETE 删除行，但数据库文件历史页可能残留，需 VACUUM / 重写文件 社区共识
  • 嵌入式场景下“擦除”等价于文件级管控：删文件最彻底 社区实测
  • 无擦除证明 社区共识

40 数据血缘与目录集成 无

无（嵌入式场景无血缘，查证为无）。

  • 无原生血缘；嵌入式定位通常不需要 官方文档。
  • 可通过上层工具链补齐 社区共识。

41 存算分离 vs 存算一体 有

有（存算一体：进程内嵌入式）。

  • 进程内嵌入式，存储即本地文件，存算一体 官方文档。
  • 无网络开销，但无法独立扩展计算/存储 社区共识。

42 多模能力 部分支持

部分支持（关系+JSON+FTS/VSS 扩展）。

  • JSON 类型，FTS（全文）、VSS（向量）为官方扩展 官方文档。
  • 无图引擎 社区共识。

43 FinOps 成本可观测性 不适用

不适用（嵌入式无计费，成本并入宿主应用）。

  • 嵌入式进程内运行，无独立计费概念，成本并入宿主应用的硬件与人力。社区共识
  • 母公司 MotherDuck 的云托管版另有按量计费。厂商口径

44 驱动与多语言生态 有

有（嵌入式驱动全：Python/R/JDBC/ODBC）。

  • Python/R/Node/Java/JDBC/ODBC 官方驱动完备 官方文档。
  • 零依赖安装是开发体验优势 社区共识。

45 物化视图 无

无（查证为无；CTAS 模拟）。

  • 无物化视图（查证为无）官方文档。
  • 用 CREATE TABLE AS + 定时重建模拟 社区共识。

46 支持跨云 不适用

不适用（嵌入式，无云绑定）。

  • 嵌入式库，跑在哪里由宿主决定，无云厂商绑定 官方文档。
  • 跨云概念不适用，文件拷到哪里算哪里 社区共识。

47 热点数据更新能力 部分支持

部分支持（乐观并发冲突即回滚，应用负责重试）。

  • 并发原语为进程内乐观并发（MVCC+undo buffer），无行锁；纯 append 永不冲突，但两个线程同时更新同一行会触发写冲突检测 官方文档。
  • 冲突时后来者直接 abort，抛 TransactionException（"Conflict on update!"），内核与驱动都不重试，应用必须捕获后整体重执事务，重试逻辑全在应用层 社区实测。
  • 热点打到同一行上意味着持续 abort：并发度越高失败率越高，TPS 在重试风暴下崩塌；单文件单写进程是硬瓶颈，第二个进程的写连接会被文件锁直接挡住 社区共识。
  • 未找到官方命名或文档化的热点行机制的证据；列存引擎下高频点更新本身即反模式 待验证。
  • 推荐模式是单写者队列或微批 append-only 建模（append 永不冲突），代价是放弃并发写入并引入队列串行化延迟与运维复杂度 社区共识。

招牌能力

每个特性 = 它是什么 + 为什么是真本事 + 推到边缘会发生什么。

  1. 进程内向量化执行：单机分析性能的第一性原理 真本事：算子一次处理 2048 行的列向量（非逐行火山模型），配合 morsel-driven 并行（Leis 等，SIGMOD 2014）把数据切成 morsel 丢进线程池动态调度，列存 row group（约 12 万行）+ zonemap + 轻量压缩（FSST/ALP/Chimp/字典/RLE/bitpacking）。社区实测：TPC-H SF10（约 11GB）22 条查询 4.3 秒跑完（i7-13700H，嵌入版 v1.5.2）。 边缘真相：快的是"单机多核扫描聚合"；preserve_insertion_order 默认 true 为保序付出代价；小查询有固定开销；TB 级以上或巨型 shuffle 依然是 Spark/数仓的地盘。单机上限是物理定律，不是调优问题。
  2. 零导入查文件：SQL 直接对 Parquet/CSV/S3 真本事：SELECT * FROM 's3://bucket/*.parquet' 即查即走，列裁剪 + 谓词下推 + 分区消除（hive 分区）让几十 GB 文件常常只读几 MB；CSV/JSON 自动嗅探 schema。探索和 ETL 的"先建表再导数"整段消失。 边缘真相：CSV auto-detect 会猜错分隔符/类型/日期（生产管线必须显式关 auto_detect）；远程文件延迟进 P99；同一文件被反复高频查询时，导入成 DuckDB 表更快。以及：这是"读"神器，"写回 Parquet"是另一回事。
  3. 零运维嵌入：pip install 就是部署 真本事：单二进制/单 pip 包，无 server、无端口、无配置，Python/R/Node/Java/Rust/Go/WASM 全语言绑定，DataFrame 零拷贝直查。把分析能力嵌进应用、notebook、CLI、边缘设备的摩擦力趋近于零。 边缘真相：省掉的运维没有消失，只是转移——备份、监控、多用户、权限全部变成应用层的责任（见硬维度：四项不适用）。"免运维"是把 DBA 的工作外包给了写应用的人。
  4. 扩展生态：一个引擎，多种形态 真本事：httpfs（S3/HTTP）、spatial（GIS）、postgres/mysql/sqlite（联邦扫描）、iceberg、aws（凭证链）、json 等官方扩展；外围有 MotherDuck（serverless+混合执行）、DuckLake（开放湖仓格式，v1.0 已发布）、Quack（client-server 协议，v2.0 转正）。 边缘真相：扩展与引擎版本锁定，升级 DuckDB 后必须 UPDATE EXTENSIONS，版本错配会崩；Quack 仍是 beta，并发写线程数有限（社区口径约 8）；DuckLake/Iceberg 写支持等能力在补齐中。生态在爆发，但"稳定版"和"预览版"要分开看。

深水区

深水区一：单写者——刻在架构里的并发天花板（领域：并发模型）

  • 机制：进程内多线程写走 MVCC + 乐观并发（append 永不冲突，同行并发改后者冲突报错）；跨进程靠文件锁二选一：单进程读写，或多进程只读。
  • 推到边缘：第二个进程以写模式打开同一文件直接报 Could not set lock on file；多 worker ETL 并行写同一 .duckdb 文件必须串行化，否则第二个部署直接撞锁——这是"第二个节点上线就炸"的经典生产事故；Docker 里忘记挂 volume，容器一停数据全丢（社区高频坑）。
  • 选型含义：任何"多进程/多机并发写同一文件"的架构，DuckDB 直接出局。标准解法：单写进程 + 其他进程 ATTACH ... (READ_ONLY)，或写时分文件、读时合并；真要多用户读写，上 MotherDuck 或等 Quack 转正。这是选型第一问，答不上来后面都不用谈。
  • 来源：官方文档（concurrency）；社区共识（多独立技术文档）；社区实测（sq/neilotoole 驱动文档）。

深水区二：内存与外存溢出——"能跑 100GB"的账单（领域：资源管理）

  • 机制：统一 buffer manager 掌管进程全部内存（页缓存与算子临时内存动态互借）；memory_limit 默认 80% 系统内存；超限后阻塞算子（分组、join、排序、窗口函数）把中间结果溢出到 temp_directory。
  • 推到边缘：没有 temp_directory（或无 swap）时内存限制执行不下去，进程内存无界增长直到被 OOM killer 干掉（源码级确认）；深嵌套查询的溢出量可达数据集 30 倍且"不总是可靠"社区实测；第三方评测：50GB 输入在 16GB 机器上外存聚合比内存慢约 30 倍——"能跑"和"能用"是两回事；加密库用户若没开 temp_file_encryption，溢出的临时文件是明文（官方实现者文档警示）。
  • 选型含义：生产环境三件套必须配齐：SET memory_limit + SET temp_directory（放 SSD，留足磁盘）+ 容器内存/disk 双限额。把 DuckDB 当"无限内存"用的管线，第一个大促就是 OOM 演练。
  • 来源：官方文档（memory 管理）；社区实测（nlesc 指南、firepanda 评测）；源码注释（temporary_memory_manager.cpp）。

深水区三：存储格式与版本升级——没有"原地升级"这回事（领域：运维/升级）

  • 机制：存储格式向后兼容自 v0.10 起是官方目标；前向兼容仅 best-effort；格式变化时官方迁移路径是旧二进制 EXPORT DATABASE + 新二进制 IMPORT DATABASE。
  • 推到边缘：升级后旧文件可能直接打不开，且必须同时保留新旧两个版本的可执行文件才能迁移——CI 自动升级的单二进制部署没有迁移路径；降级更惨：新格式文件旧版本打不开，只能删库或重导；2026-02/03 曾出现 checkpoint 并发 bug 导致 WAL 回放失败、文件无法打开（后修复，但作者承认修复成立的前提是"checkpoint 期间禁删表"——恢复子系统仍在重构中）；v2.0 将切换新默认存储格式，1.x 用户要提前规划。
  • 选型含义：把"升级 DuckDB"当成一次 ETL 演练来排期：pin 版本、EXPORT/IMPORT 演练、回滚预案。关键报表库建议 pin 住小版本，因为每个补丁版都在修"wrong results"类 bug（v1.5.6 一次修了多个静默错误结果问题）。
  • 来源：官方文档（storage）；官方发布公告（1.5.6）；社区分析（powerbrowser 研究文档，PR #21067/#21285）。

深水区四：备份的诚实边界——快照有，PITR 没有（领域：备份恢复）

  • 机制：EXPORT DATABASE (FORMAT PARQUET) 利用 MVCC 读一致快照，可在线备份，输出为 Parquet 目录 + schema.sql；或关进程后拷文件。
  • 推到边缘：打开状态下直接 cp .duckdb 文件可能拷到写一半的状态，恢复出来是坏的（社区共识：必须先 CHECKPOINT，仍有竞态窗口）；删数据后文件不缩小（VACUUM 只做统计信息/空间复用，缩文件唯一可靠办法是 EXPORT+IMPORT）；无 WAL 归档、无时间点恢复——"删库跑路"的恢复点就是上次导出；真实案例：checkpoint 损坏后靠"只读 ATTACH 逐表 COPY 到新库"救回 60M 行数据（62 秒），但重建后文件从 9.0GB 膨胀到 14.2GB（压缩与插入顺序强相关）。
  • 选型含义：DuckDB 是"分析引擎"不是"交易库"——把它当唯一持久层存关键数据是架构错误；正确姿势是上游 OLTP 库（PG/MySQL）做 PITR，DuckDB 当可重建的派生层。备份策略 = 定时 EXPORT + 版本化 Parquet 目录。
  • 来源：官方文档；社区实测（johngavin 备份方案对比、osmpbudynkiv2 恢复实录）；社区共识。

深水区五：直接查文件的代价账本（领域：查询执行）

  • 机制：读 Parquet 时列裁剪 + 谓词下推 + row group 统计信息剪枝；hive 分区消除；httpfs 范围请求读远程文件。
  • 推到边缘：CSV auto-detect 在生产数据上翻车是常态（分隔符、表头、日期格式猜错），社区建议生产管线一律显式指定参数、关 auto_detect；TIMESTAMP 解析默认按本地时区，跨时区管线会静默错位；反复被查询的热文件每次都要重新解析元数据+走网络，不如 CREATE TABLE AS 导入一次；S3 上的"选择性查询"省 IO，但全表扫描的 egress 费用照付。
  • 选型含义：探索/adhoc/ETL 落地前用"直接查"，高频服务查询用"导入表"；对象存储做热查询前先算 egress 账。这是"快"的另一面：快在计算，慢（贵）在 IO。
  • 来源：官方文档；社区共识（多独立实践指南）；社区实测（DuckDB vs Spark 对比）。

深水区六：加密的合规边界（领域：安全）

  • 机制：v1.4.0+ 的 ENCRYPTION_KEY 做 AES-256-GCM 整文件加密（含 WAL 与溢出临时文件），duckdb_databases() 可查 encrypted/cipher。
  • 推到边缘：官方明确未达 NIST 合规要求（跟踪 issue #20162），强合规行业（金融/医疗）评审会卡住；密钥丢失 = 数据永久不可恢复，无任何后门；不支持原地加解密与轮换，轮换 = COPY 到新库（停机窗口）；加密的只是 .duckdb 文件——COPY TO 导出的 Parquet/CSV 是明文，冷数据要靠卷加密或对象存储 SSE。
  • 选型含义：加密解决了"丢盘/丢文件"的威胁模型，解决不了"能读进程内存/能读密钥的人"；合规 checklist 上它算"有"，但"有"和"够"是两回事，先问审计要什么再选。
  • 来源：官方文档（1.4.0 公告、encryption 博客）；社区实测（efcoreprovider 加密文档）。

客户经验

内核 进程内 OLAP：pip install 即拥有的分析引擎

一句话
以库的形式链进你的进程：无 server、无端口、无守护进程，直接对 Parquet/CSV/S3 做向量化 OLAP——笔记本、CI、边缘设备、Lambda 里都能跑。
窄场景
数据科学家笔记本里 GB~百 GB 级分析（SELECT 直接查 Parquet 文件，无需建库导数）；ETL 管道里的变换算子（替代 pandas 的内存效率、Spark 的部署重量）；Serverless 函数（单 binary、无依赖、冷启动快）。
机制
列存 + 向量化执行（借鉴 MonetDB/X100 研究），但关键差异在部署形态：进程内意味着零 IPC/网络开销、零运维。对比 Spark（同样做聚合要起 JVM 集群）、pandas（行式内存模型在 group-by/join 上慢一个量级且内存爆炸）。读 Parquet in-place（文件夹即表）是另一机制要点。MotherDuck 的总结："Simplify. Replace Apache Spark with DuckDB where possible."
生产验证
FinQore（原 SaaSWorks，金融）：财务 ETL 管道 PostgreSQL→DuckDB，8 小时→8 分钟（https://github.com/cyyeh/skills-playground/blob/HEAD/examples/system-explorer/duckdb/06-use-cases.md）；Stockly：数据工程师用 DuckDB 做 TB 级数据迁移引擎替代 pandas（"We're talking terabytes, and Pandas is not really fitted for this"，Medium 具名访谈）（https://medium.com/@admin_31497/duckdb-in-practice-migrating-terabytes-with-sql-first-analytics-3ee735149f22）；MotherDuck 梳理 15+ 生产用例（Rill、Evidence、Mode、Hex、Mosaic、Count 等产品内嵌）（https://MotherDuck.com/blog/15-companies-duckdb-in-prod/）。诚实备注：FinQore/Stockly 为社区转述，已降档。
竞品差距
ClickHouse/StarRocks/Doris 都是 server 形态，要部署、要运维、要网络；10GB 以下单机场景 DuckDB 通常更快社区共识。SQLite 同为嵌入式单文件但行存 OLTP——"same niche, opposite workload"。20GB 日志分析社区对比：DuckDB ~15 秒 vs PostgreSQL 3-5 分钟。31 款中"进程内 + 列存向量化 + 直接读 Parquet"的产品没有第二家。
证据等级
社区共识 + 具名生产案例（部分为社区转述，已标注）
最后核验
2026-10-01

生态 被嵌入的分析引擎：BI 产品的"标配内核"

一句话
Rill、Evidence、Mode、Hex 等一线数据产品把 DuckDB 编译进自己的应用做查询引擎——DuckDB 的招牌不在终端用户，而在"被选为内核"。
窄场景
嵌入式/客户-facing 分析产品（每个用户一个轻量、高速、可随应用分发的 OLAP 内核）；浏览器内分析（DuckDB-WASM 让 1800 万行 Gaia 星表在浏览器里可交互探索）。
机制
C++ 核心 + 多语言 binding + WASM 编译能力，使它成为"分析引擎界的 SQLite"：产品方 pip install 或 npm 一个 wasm 包就获得完整 SQL OLAP。Mode 的 Helix 故事最有说服力：最初用 VoltDB（内存 OLTP），"pushed it to its limits"——OLTP 行存做 MEDIAN/PERCENTILE/RANK 这类分析函数是灾难；换 DuckDB 后两年生产，Helix + 可视化 + schema/索引服务 + ingestion 服务全跑在 DuckDB 上，每天数百万查询。
生产验证
Mode 数据平台负责人 Eddie Tejeda（2024-10 原文）："After two years in production, DuckDB powers not only Helix and our visualizations but also our schema and indexing service and our ingestion service… millions of queries per day."（https://medium.com/@eddietejeda/the-real-world-impact-of-using-duckdb-and-what-it-means-for-modern-data-platforms-dcedaff575cc）；Rill 内部基准比 SQLite 快 3-30 倍；Hex notebook 切换 DuckDB 后执行快 5-10 倍；Evidence 用 DuckDB-WASM 构建 Universal SQL 查询引擎（https://motherduck.com/blog/duckdb-enterprise-5-key-categories/）。
竞品差距
31 款中没有第二家能被 pip install 进 Python 进程、编译进浏览器、塞进 Lambda。ClickHouse 有 chDB（嵌入式尝试）但生态声量不在一个量级。DuckDB 的护城河是"被集成"，不是单机性能数字。
证据等级
具名生产案例（Mode 为一线负责人亲述，证据最强）+ 社区共识
最后核验
2026-10-01

内核 边缘/离线分析：断网也能跑的 OLAP

一句话
无网络依赖的完整 SQL 分析能力：数据落本地文件（Parquet/CSV），DuckDB 在设备端直接出 KPI，恢复联网后再同步云端。
窄场景
工业现场（隔离网络）、船舶/石油钻井平台、野外科研、网络不稳定的零售门店、灾害响应；架构模式：本地 append 事件 → DuckDB 定时查 → 本地 dashboard → 夜间同步云端。
机制
云数仓的假设是"网络永远可用"，边缘场景的网络是第一受害者。DuckDB 进程内 + 单文件 + 零依赖，装进平板/工控机/浏览器即可；WASM 版本甚至让"分析"发生在最终用户的浏览器里，服务器只负责同步文件。这是架构层面的不可替代：任何 server 形态的 OLAP（ClickHouse/StarRocks/Doris）都做不到"断网可用"。
生产验证
社区实践长文（Medium，ThinkingLoop，2026）系统梳理工厂 shift dashboard、船舶、灾害响应等真实边缘模式："answers now, sync later"（https://medium.com/@ThinkingLoop/duckdb-on-the-edge-analytics-without-wi-fi-ce121cc58e61）；南澳政府 duckdb-wasm 驱动气候数据 dashboard，浏览器内直接跑分析查询（链接见招牌 1）。诚实备注：边缘场景的具名企业案例不如 BI 嵌入类丰富，多为模式总结。
竞品差距
31 款中没有。所有 server 形态 OLAP 都要求网络；SQLite 能在边缘跑但是 OLTP 行存。这是 DuckDB 独占的窄场景。
证据等级
社区实践 + 具名生产部署（南澳政府）
最后核验
2026-10-01

避坑 单写者 + 无 Server：并发与多租户的天花板

一句话
同一文件同一时间只允许一个进程写；多进程写会 block 或直接失败——这是架构的故意取舍，也是 DuckDB 所有"不能用"场景的总根因。
窄场景
谁最容易中招——想拿 DuckDB 当"便宜数仓"给几百个 BI 用户并发查询的团队；多副本/多进程同时写入同一 .duckdb 文件的部署；SaaS 多租户需要行级隔离而非"每租户一文件"时。
机制
DuckDB 刻意不做多进程写并发：没有分布式锁管理器、没有共享 WAL 恢复——取舍换来的是单机性能与代码简洁。代价是硬边界：第二个带写权限打开同一文件的进程会卡在文件锁上；生产布局必须是"一个写进程 + 其他进程只读 ATTACH"。社区共识的判据："brilliant for analysis on one machine and wrong for multi-user serving"；"under ~10GB on one box DuckDB usually wins; pick ClickHouse when many people query concurrently."
生产验证
社区生产布局经验（forge-orm）："A foot-gun the adapter cannot prevent: DuckDB is single-writer… Plan for this up front — it's the difference between 'embedded analytics that just works' and 'the second deploy collides with the first'."（https://github.com/johnsonfash/forge-orm/blob/HEAD/docs/DUCKDB.md）；BI 选型 rubric（Basedash，2026）量化了边界：工作集 <100GB 可闭眼用，并发"up to a few dozen"干净、hundreds 请用云数仓或 MotherDuck（https://www.basedash.com/blog/duckdb-for-bi-when-single-node-analytics-beats-a-cloud-warehouse）。
竞品差距
这正是 MotherDuck 存在的理由（serverless 托管 DuckDB 解决多用户），也是 ClickHouse/StarRocks/Doris 这些 server 形态 OLAP 的主场。招牌 1-3 的每一条正面，都以这条反向为边界。
证据等级
社区共识（高度一致，无分歧）
最后核验
2026-10-01

用户最买账的 5 点

  1. 单机分析性能，"小机器跑出集群感"
    • 为什么是真的：向量化（2048 行/向量）+ morsel 并行 + 列存剪枝是架构级优势，不是调优技巧；社区实测 TPC-H SF10 22 查询 4.3 秒；i7 级笔记本处理几十 GB 是日常。
    • 边缘与限度：甜蜜点在 GB~数百 GB；TB 级以上、巨型分布式 shuffle、流式，依然是 Spark/数仓的地盘；"比 pandas 快 10~100 倍"的对比成立的前提是"数据已超出内存舒适区"，小数据上 pandas 启动更快。来源：社区实测；观察版本：v1.5.2。
  2. Python/Arrow 零拷贝集成，"pandas 不够大、Spark 太重"之间的答案
    • 为什么是真的：duckdb.sql("SELECT ... FROM df") 直接查 DataFrame，无需 register；Arrow 零拷贝双向流通；Polars 互操作顺滑。数据科学家不用离开 notebook 就有完整 SQL。
    • 边缘与限度：替代的是"数据处理"不是"pandas API"——df.groupby().agg() 链式代码要重写成 SQL（chDB 这类方案才保留链式 API）；UDF/复杂 Python 逻辑下推有限。来源：官方文档 + 社区共识；观察版本：v1.5.x。
  3. SQL 方言好用，"写着爽"
    • 为什么是真的：QUALIFY（窗口函数直接过滤）、PIVOT/UNPIVOT 原生、嵌套类型（LIST/STRUCT/MAP）+ UNNEST、宏、对标 PG 的函数库。分析师从"CTE 套 CTE"里解放。
    • 边缘与限度：方言甜点不等于 PG 兼容——存储过程、触发器等 PG 特性没有；从 PG/MySQL 迁分析负载要过一遍函数差异；VARIANT/GEOMETRY 等新类型在 1.5 仍在打磨（v2.0 重写 VARIANT）。来源：官方文档 + 社区共识；观察版本：v1.5.x。
  4. 部署零摩擦，"pip install duckdb"
    • 为什么是真的：单二进制/单包，无 server、无端口、无配置；WASM 直接跑浏览器；Docker/边缘/CI 里即插即用。把"搭个分析环境"从半天变成一条命令。
    • 边缘与限度：零摩擦的是"跑起来"，生产化（备份、内存配额、版本 pin、多用户）一件都少不了；npm 旧包 duckdb 已废弃，要迁 @duckdb/node-api。来源：官方文档 + 社区共识；观察版本：v1.5.x。
  5. MIT 开源 + 基金会治理，"收购也拿不走"
    • 为什么是真的：MIT 无功能阉割；IP 在独立非营利基金会手里；2026-08 AWS 收购的是 DuckLabs 公司，开源项目治理与许可不变（AWS 官方博客口径）；社区 star 数万、日下载量百万级厂商口径。
    • 边缘与限度：许可是 MIT，路线图话语权仍在核心团队/雇主手里；收购后"技术咨询委员会""开放扩展签名"等承诺尚未交付待验证；生产级支持依然要买服务。来源：官方 history + AWS 官方博客；观察版本：2026-09。

吐槽清单

分类吐槽影响版本状态
运维坑单写者：第二进程写同一文件直接报文件锁错误；多 worker 并行写必须串行化或分文件全版本open（架构性；Quack 转正前无解）
运维坑无服务端能力：认证、审计、慢查询日志、会话管理一概没有，全是应用层的事全版本open（架构性）
运维坑存储格式升级无原地迁移：必须"旧二进制 EXPORT + 新二进制 IMPORT"，CI 自动升级的单二进制部署没有迁移路径全版本open
运维坑降级无恢复：新格式文件旧版本打不开，只能删库或重导全版本open
运维坑扩展与引擎版本锁定：升级后必须 UPDATE EXTENSIONS，错配会崩全版本open
运维坑Docker 忘记挂 volume，容器停止数据即丢全版本open（用法坑）
运维坑PRAGMA integrity_check 不存在；无 duckdb_queries()/duckdb_connections()，跨会话可观测性缺失v1.5.x 实测open
性能坑无 temp_directory 时 memory_limit 执行不下去，大查询 OOM 被系统杀掉全版本open（必须显式配置）
性能坑深嵌套查询溢出量可达数据集 30 倍且不稳定；外存聚合比内存慢一个数量级全版本open（架构现实）
性能坑删数据后文件不缩小：VACUUM 不缩文件，唯一可靠办法 EXPORT+IMPORT全版本open（架构现实）
性能坑preserve_insertion_order 默认为 true，为保序付出可观性能代价全版本open（可关）
兼容坑CSV auto-detect 生产翻车：分隔符/类型/日期猜错；TIMESTAMP 默认按本地时区解析致跨时区错位全版本open
兼容坑无 SAVEPOINT；外键 DDL 可建但写时不强制（社区口径，待验证）全版本open
兼容坑npm 旧包 duckdb 已废弃，需迁 @duckdb/node-api（prebuilt 二进制，不再源码编译）1.4+fixed-in-v1.4.x（迁移指引）
版本坑每个补丁版都在修 "wrong results" 类静默错误（如 v1.5.6 修 LIMIT/UNNEST/Top-N 下推错误结果），关键报表必须 pin 版本 + 回归1.5.xpartially-fixed（持续修复中）
版本坑checkpoint/WAL 并发恢复 bug 曾致文件无法打开（2026-02/03），恢复子系统仍在重构1.5.x 早期partially-fixed
生态坑Quack client-server 仍 beta，并发写能力有限（社区口径约 8 线程），多用户读写生产未到火候v1.5.xopen（v2.0 转正待验证）
成本坑MotherDuck 按计算秒计费：突发/低效查询直接变账单；数据出境与驻留需过安全评审托管服务open

判决

  • 适合谁：笔记本/单机上的数据分析与探索；Python 数据科学管线（pandas 瓶颈后的第一升级）；轻量 ETL（CSV/Parquet/S3 落地）；嵌入式分析（应用内、边缘、WASM）；CI/测试里的 OLAP 断言；GB~数百 GB 的交互式分析。
  • 不适合谁：多进程/多用户并发写；OLTP 与高频小事务；需要认证/审计/行列权限的合规系统；TB 级以上分布式分析；7×24 服务端 SLA 场景；把 DuckDB 当唯一持久层存关键数据。
  • 迁移成本：pandas/polars → 低（主要是把链式 API 重写成 SQL）；PG/MySQL 的分析负载 → 低-中（方言差异逐项过，ATTACH 可做联邦过渡）；Spark/数仓 → 中（分布式作业重写 + 数据规模先降到单机装得下）；传统 BI 报表 → 中（报表语义回归 + 版本 pin）。

来源与待验证清单

  • 历史与治理：duckdb.org/history（官方；2018 CWI 起步、2019 SIGMOD v0.1、2021-07-14 DuckDB Labs spin-off、DuckDB Foundation 持 IP、MIT；2026-05 更名 DuckLabs；DuckLake 1.0 2026-04-13；Quack 2026-05 技术预览；2026-08-26 DuckLabs 加入 AWS）
  • 收购口径：AWS News Blog 2026-08-31（官方口径：收购 DuckLabs 公司，开源项目归基金会、MIT 不变）
  • 版本：duckdb.org 2026-09-28 公告 v1.5.6（当前最新；1.4.x LTS）；v2.0-alpha"Cyanoptera"预览（Quack v1.0、新 PEG 解析器、新存储格式，计划 2026-10 发布——官方 preview 口径，落地待验证）
  • 加密：官方 1.4.0 发布公告（ENCRYPTION_KEY、AES-256-GCM、覆盖主文件/WAL/临时文件）；官方 encryption 博客 2025-11-19（AES-GCM-256/CTR-256；NIST 未合规，issue #20162）
  • 并发与存储：官方文档 concurrency（单写者/MVCC/乐观并发/文件锁）；官方文档 storage（向后兼容自 v0.10、前向 best-effort、EXPORT/IMPORT 迁移）
  • 执行引擎：社区技术解析（2048 向量、morsel-driven 并行 SIGMOD 2014、列存 row group/zonemap/FSST/ALP/Chimp 压缩、DPhyp 优化器）——多独立来源交叉，机制级为社区共识
  • 社区实测：MariaDB 官方仓库嵌入 DuckDB 的 TPC-H SF10（22 查询 4.30s，v1.5.2）；firepanda 评测（50GB/16GB 外存聚合慢约 30x）；nlesc 指南（深嵌套 spill 30x）；osmpbudynkiv2 恢复实录（checkpoint 损坏、62 秒重建、9.0GB→14.2GB）；libredb-studio v1.5.5 探针（无 integrity_check/duckdb_queries/duckdb_connections）；juanlara18（DuckDB vs Spark 500GB 分界）
  • 社区共识（多独立来源）：单写者文件锁、内存默认 80%、无 temp 目录限不住内存、扩展版本锁定、CSV auto-detect、时区、SAVEPOINT 缺失
  • 待验证：Quack 并发写上限（单社区口径约 8 线程）；外键写时强制状态（单社区口径）；v2.0 正式发布时间；AWS 收购后基金会治理变化（技术咨询委员会、开放扩展签名）
  • 下次评审：跟踪 v2.0 正式发布（存储格式、Quack 转正、VARIANT 重写）后重写"存储格式与版本升级""复制与一致性"条目；复核 NIST 合规进展（issue #20162）