DuckDB 周报：从一个库到一个栈，DuckDB 正在改写分析引擎的游戏规则

摘要：本周 Simon Willison 研究 DuckDB 沙箱安全、Definite 公开"从 Snowflake 迁移到 DuckDB 降本 70%"的完整账本、DuckDB 被称作"小型 Spark 的终结者"。DuckLake 生态持续发酵——多篇文章从不同视角分析了这个"用 SQL 数据库做元数据"的另类湖仓格式。

Nevenka Lukic 在 Towards Data Engineering (Medium) 上发表了一篇引发讨论的文章——"DuckDB: The Death Of Small-Scale Spark"。
核心论点：当大家都在争论分布式计算引擎的未来时，一个单二进制文件正在悄悄取代大多数场景下的 Spark 集群。

文章梳理了两条路径：如果你的数据规模在几百 GB 以下（这覆盖了绝大多数公司），DuckDB 的嵌入式、零运维模式，比维护一个 Spark 集群划算得多。DuckDB 的向量化执行引擎在单机上的性能，已经超越了大多数分布式方案的冷启动+网络开销后的实际表现。
这篇文章的价值不在于技术深度，而在于它用一个鲜明的观点，把"何时该用 DuckDB"这个选择困境推到了桌面上。

6月10日，Simon Willison 发布了一则研究笔记——"Can DuckDB run untrusted SQL as safely as Datasette runs SQLite?"。
这是 Datasette 一直以来的核心能力：让用户在浏览器里写 SQL，但绝不会碰到数据库之外的任何文件。Simon 的答案是：可以，但比 SQLite 需要更多配置。
SQLite 通过引擎级别的只读连接和基于操作码的超时限制，天然防止了非授权文件和网络访问。DuckDB 的 read_only=True 选项本身不够——Simon 的实验建立了一套更严密的沙箱策略：禁用 load 扩展、限制文件系统访问、配置网络白名单。
对于运行 DuckDB 作为后端服务的团队来说，这篇研究非常及时。当 DuckDB 从嵌入式库变成服务端组件时，安全边界问题就变得不可回避。

本周 DuckLake 的讨论明显升温。三篇文章从不同角度剖析了这个"用 SQL 做元数据"的湖仓格式。

6月5日，SparkIngScala 发布了一篇异常扎实的分析——"DuckLake: A New Lakehouse Format That Stores Metadata in SQL"。
文章的核心洞察是：DuckLake 不是表格式，是目录格式。它不是 Iceberg 或 Delta Lake 的直接替代，而是对栈的上半层（"Iceberg + Polaris" 或 "Delta + Unity"）的替换。

三个实打实的优势：

1. 元数据读取快：Iceberg/Delta 的冷元数据读取需要列出并解析 S3 上的文件，每次查询计划就要花费数百毫秒。Postgres 上对 ducklake_snapshot 表的索引查询，几毫秒就返回了。
2. 没有小元数据文件问题：Iceberg 每次提交至少写入一个 manifest 文件；Delta 每次提交追加 JSON 条目。高频写入者积累成千上万个元数据文件，不得不定期清理。DuckLake 只需提交数据库行。
3. 多表事务：因为目录是一个真正的数据库，你可以用 BEGIN/COMMIT 包装多表写入。Iceberg 和 Delta 都缺乏原生的多表 ACID。

诚实的代价清单：

• 你需要运维一个数据库（Postgres/MySQL）。对于已有 PG 的团队几乎免费，但对于追求"无状态湖仓"的团队，这是一个真正的架构新增。
• 在极致规模下尚未验证。Iceberg 在 Netflix/Apple 支撑 PB 级和百万级文件，DuckLake 生产记录还没到这个量级。
• 引擎支持是 DuckDB 优先。截至 2026 年 6 月，还没有原生的 Spark 读取器。需要通过 Iceberg 互操作（COPY FROM ICEBERG/COPY TO ICEBERG）做数据导出。

给 Spark Scala 团队的三条建议：

• 已经在用 Iceberg/Delta 且运作良好 → 继续用。迁移成本高于你从 DuckLake 获得的元数据延迟收益。12 个月后再看。
• 从零搭建湖仓，规模中等 → DuckLake 值得认真考虑，尤其是你已经运行 Postgres 并且用 DuckDB 做 BI。
• Spark + DuckDB 并行使用 → DuckLake 提供了一个更自然的共享基板。

DuckDB Lab 发布了一篇实操教程——"DuckDB AI Data Lake: Lance Vectors + Iceberg Lakehouse in Practice"。
这篇文章的看点不是概念，而是完整的端到端架构：

1Raw Data (CSV/JSON/DB)

2       ↓ DuckDB SQL ETL

3   Iceberg Data Lake (versioning + MERGE INTO)

4       ↓

5  ┌────┴─────┐

6  Lance Vectors   Relational Tables

7  (vector search) (BI/analytics)

8  └────┬─────┘

9       ↓

10  Hybrid Search (vectors + keywords)

11       ↓

12  RAG / Recommendations / Analytics Products

关键能力：

• 纯 SQL：向量嵌入、业务数据、版本历史全部存在同一个 Iceberg 表中，通过 DuckDB 的 Lance 扩展做向量索引和混合搜索（lance_hybrid_search），alpha 参数控制向量/关键词权重。
• MERGE INTO 做实时 upsert：Iceberg 的 MERGE INTO 可以一次性处理文档的新增和更新，不再需要复杂的 ETL 逻辑。
• 与传统方案对比：传统方案需要 Postgres + FAISS + Airflow 四五个服务，DuckDB AI 数据湖只需要一个 DuckDB 进程。

教程最后还给出了商业化建议：RAG SaaS 产品（$70-300/月/企业）、自动数据分析报告（$30-70/份）、数据即服务（按 API 调用计费）。

pdpspectra 发表了一篇行业视角的综述——"DuckDB Extensions in 2026: MotherDuck, DuckLake, and the Local-First Data Platform"。
文章把 DuckDB 的 2026 年定位概括得很精准：问题不再是"DuckDB 能不能上生产"，而是"什么时候该升级到 Snowflake 或 Databricks"。
DuckDB 从嵌入式的单文件分析引擎，变成了一个完整的"本地优先"数据平台——通过 httpfs 直读 S3、通过 postgres/mysql/sqlite 扩展查询远程数据库、通过 ducklake 管理元数据、通过 MotherDuck 做云端协作。
文章列出了现实中真正有用的扩展：httpfs、postgres/mysql/sqlite、iceberg/delta、ducklake、fts、json、spatial、vss、excel。
关于 MotherDuck 的评估也很诚实：对于 10 人以下、几 TB 数据的小团队，MotherDuck 确实比 Snowflake/Databricks 便宜一个数量级。但 MotherDuck 是一家小公司，集中化风险真实存在。
"何时升级"的判决：当数据量超过 ~10 TB、查询并发持续高于数十个用户、需要集中目录和行级安全时，就可以考虑 Snowflake/Databricks/BigQuery 了。好消息是升级路径通常是干净的——DuckDB SQL 稍作调整就能在仓库上运行，Parquet 文件直接迁移。

本周最重量级的内容来自 Definite（一个全栈分析平台）的 CEO Mike Ritchie 发布的文章——"DuckDB & DuckLake: Why We Bet the Company on the Duck Stack"。
这不是一篇概念验证，而是一个真实的生产迁移故事。

Definite 是一个"all-in-one"分析平台（连接器 + 仓库 + BI + 语义层 + AI）。2024 年 5 月，他们决定将整个基础设施从 Snowflake 迁移到 DuckDB。

他们评估了 Postgres、ClickHouse、Snowflake 和 DuckDB：

• Postgres：行式 OLTP 数据库被要求做 OLAP 工作，大数据集下性能急剧下降。
• Snowflake：在 Snowflake 之上建分析平台，既有财务依赖（信用点计费让双边经济无法成立），又有架构依赖。
• ClickHouse：需要分布式集群，运维开销大，设计场景（几十亿行/秒摄入、PB 级实时仪表盘）与大部分客户工作负载不匹配。
• DuckDB：可嵌入、与 Postgres 兼容的 SQL、按 VM + 对象存储计费而不是按信用点——单位经济直降一个数量级。

• 计算层：DuckDB 运行在 GKE 容器中，Rust 编写的 DuckDB 服务器处理连接池、查询路由和生命周期管理。
• 存储层：所有数据以 Parquet 格式存在 GCS 上，计算与存储分离，DuckDB 直接读取。
• 并发模型：最初用读写实例分离模式，后构建 Flight 服务器做流式负载，现在 DuckLake 通过 Postgres 协调查彻底解决了并发问题。
• 数据摄入：自建 target-ducklake（Meltano 兼容），200+ 数据源连接器直通 DuckDB 引擎。

DuckLake v1.0（2026 年 4 月）让 Definite 的架构变得更简单。文章给出了一个极具冲击力的成本对比表：

这不是 20% 的节省，这是一个数量级。

一台现代 16 vCPU、64GB RAM 的机器，运行 DuckDB，可以在亚秒级处理数百 GB 的分析查询。不需要节点管理、不需要冷启动、不需要担心"有个人留了一个 Large warehouse 跑了一整周"。

6月6日提交、6月8日更新的一个值得关注的 issue：当 DuckDB 线程数增加到 3 个或更多时，内存消耗呈爆炸式增长。看起来每个新线程都在复制而不是共享某些内存结构。这是一个比较严重的影响生产的问题，建议关注后续修复。

DEV Community 对 DuckDB 4月发布的数据内联特性做了回顾性介绍——DuckLake 的新数据内联特性通过将小文件直接存储在目录数据库中，解决了流式数据湖的"小文件问题"。基准测试显示该特性在特定操作上实现了 926x 的加速。

• MotherDuck 六月生态通讯（原文）—— Simon 的月度汇总，涵盖 Quack 协议、DuckLake 冰等——本月的内容和本篇文章有很多重叠，可以互相补充。
• DuckDB 在 DuckLake 上的多表事务与时间旅行（duckdblab.org）——如果你对 Lance + Iceberg + DuckDB 的 AI 数据湖路线感兴趣，这个教程值得细读。
• DuckCon #7 阿姆斯特丹（duckdb.org）——6月24日，正在倒计时。

这一周的 DuckDB 生态传递了一个清晰的信号：DuckDB 已经从"一个快的嵌入式分析引擎"进化成"一个完整的数据平台栈"。
从 Simon Willison 的安全沙箱，到 Definite 的生产级迁移案例，到 SparkIngScala 的 DuckLake 工程分析，到 pdpspectra 的扩展全景——各方的共同叙事是：对于绝大多数公司的分析负载，单机 DuckDB + Parquet + 对象存储，已经是一个足够好且便宜一个数量级的方案。
DuckLake 作为其中的关键拼图，正在经历从"新概念"到"生产级"的过渡期——元数据快、运维简单、生态正在追赶。是否能在大规模场景下站住脚，未来 12 个月是关键窗口。

本期整理自 DuckDB 官方博客、Simon Willison Weblog、Definite Blog、SparkIngScala、DuckDB Lab、pdpspectra、DEV Community、GitHub Issues 等渠道，发布于 2026 年 6 月 14 日。