DuckDB，正在悄悄吃掉湖仓

一份生态月报，通常只有社区的人才会看。但 2026 年 10 月的 DuckDB 生态月报，值得所有做数据平台的人认真读一遍。

理由不复杂：这条月报里的每一件事——AI 答案直接落进 DuckDB 和 MotherDuck SQL 执行、2.0 版本的 PEG 解析器与异步 S3 读取、DuckLake 的持续维护、分析就绪的 OpenStreetMap、进浏览器的 OneLake、原生 Mac 应用——拼在一起，指向的是同一个判断：分析型数据基础设施的入口，正在从“平台”回到“引擎”。（这属于本文的观点，后文会给出理由，也欢迎读者反驳。）

过去十年，数据行业的叙事是往上走的：从数据库到数据仓库，从数据湖到湖仓一体，平台越做越重，预算越花越大。而 DuckDB 这只小黄鸭，用十年的社区积累，正在悄悄反向拆解这套叙事。

🦆 AI 开始绕过平台，直接敲引擎的门

月报里最有想象空间的，是 Jev 在 DuckDB 与 MotherDuck SQL 里直接输入 AI 答案这件事。

什么叫"typed AI answers"？简单说，就是 AI 生成的分析与答案，不再停留在聊天窗口里，而是被直接输入到 DuckDB 和 MotherDuck 的 SQL 环境中执行、验证、落地。AI 不再是给你讲一段话的助手，而是直接上手干活的分析员。

这个动作很小，含义很大。过去 AI 辅助分析的链路是：用户提问 → AI 生成 SQL → 用户复制到客户端 → 执行 → 再贴回去问。而现在，引擎本身就是 AI 的工作台。

越来越多的 agent 工作流已经把 DuckDB 当作本地执行的默认底座——这是笔者从社区讨论和公开案例中得到的观察，属于推测而非经过统计验证的结论。但它至少解释得通：DuckDB 启动快、零部署、单文件即用，AI 调用它几乎没有任何摩擦成本。

产业逻辑在这里可能正在发生倒转。以前的路径是：先买平台，平台里长出分析能力。现在的路径是：AI 直接面对一个高性能引擎，平台变成引擎背后可选的存储与治理层。入口变了，商业模式的变数就会跟着变——当然，这只是本文的判断。平台厂商在治理、权限、合规上的能力，短期内仍然是 agent 无法绕开的，Snowflake 与 Databricks 也远没有到被“绕过”的地步。真正值得注意的，是趋势的方向，而不是它的速度。

⚡ 2.0 的两张王牌：PEG 解析器与异步 S3 读取

一句话开场：引擎的竞争，最后拼的都是最底层的那几百行代码。

DuckDB 2.0 的两个关键升级，月报写得很克制：PEG parser，以及异步 S3 读取。但懂行的都知道，这两件事分别动了分析引擎的“嘴”和“腿”。

先说 PEG 解析器。解析器是 SQL 引擎的入口，方言兼容、复杂查询、错误提示，全看解析器的成色。用 PEG（解析表达文法）重写解析器，意味着 DuckDB 在 2.0 这个大版本上，选择把最枯燥、最难出 PRD 的一层推倒重来。这种事商业公司通常排不上优先级，开源社区反而干得动——因为没有季度财报要交代。具体的设计动机与实现细节，可查阅 DuckDB 官方博客（duckdb.org/blog）与 GitHub 仓库（github.com/duckdb/duckdb）的 release notes。

再说异步 S3 读取。这是更直接的性能牌：对象存储上的远端数据读取，延迟是大头，把同步等 RTT 变成异步并发拉取，本质上是把网络等待时间藏进计算里。对一个以“直接查湖上数据”为核心场景的引擎来说，这一步等于把 DuckDB 和湖仓平台之间的最后一段距离又缩短了一截。

很多人还在用“嵌入式玩具数据库”的眼光看 DuckDB，但基准数据早就给出了另一个答案。DuckDB 官方博客曾公开在单机上完整跑完 TPC-H SF3000（约 3TB 数据）的查询耗时明细（见 duckdb.org/blog 的 "TPC-H at SF3000" 一文），所有 22 条查询在分钟级内完成——这是多数分布式平台都要摆出集群才能做到的事。而在 Mark Litwintschik 长期维护的公开基准（tech.marksblogg.com）里，DuckDB 在十亿行级 Parquet 数据集上的单机查询表现，长期与 ClickHouse、Polars 处在同一量级区间。具体数字请以原始博客为准，但结论方向是一致的：单机内核吃下云上数据，正在从“能不能”变成“能做到什么程度”。

🗺️ 竞争格局：引擎复兴，平台承压

把视野拉开，当下分析引擎这一局的格局，可以这样摆：

（说明：上图是本文基于公开信息的主观定位，坐标值不代表任何量化评估，仅用于表达结构关系。）

左上和右上的张力，就是这一轮的主线。DuckDB 用最小的形态，攥住了很高的开发者心智；MotherDuck 作为其商业化公司，在中间地带架桥；而重型平台则要一边讲 AI 叙事，一边持续回答性价比的质疑。

水面上的进展大家都看得见，但支撑这些进展的隐性投入往往被忽略：

需要说明：这张图展示的是“显性与隐性投入”的对比，而不是给 DuckDB 划定什么“护城河”。开放生态的领先是流动的——ClickHouse、Polars、单机上的其他引擎，随时可以跟进同样的工程路径。平台真正的壁垒，从来是治理、权限、生态这些“重型件”，它们不会因为一份月报就消失。但当 AI agent 开始绕过 UI 和工作流、直接面向引擎编程时，这些重型件对轻量分析场景的拦截作用，确实在变弱。

🏗️ 湖仓的边界，被三件事同时撬动

月报剩下的几条，单独看都不大，放在一起看就很有意思。

第一件，DuckLake 持续维护。DuckLake 是 DuckDB Labs 押注的湖上表格式（文档见 ducklake.select），让 DuckDB 引擎可以以更直接的方式管理湖上数据。它的持续投入说明：DuckDB 社区不满足于“查个本地文件”，而是想成为湖仓架构里的一等公民。数据格式之争，正在从 Iceberg 一家独大，慢慢变成多方参与。

第二件，OneLake 进浏览器。OneLake 是 微软 Fabric 体系的核心数据底座，把它的浏览与交互直接搬进浏览器（见 Microsoft Fabric 官方更新公告），等于把“数据探查”这个环节从重型客户端里解放出来。注意一个细节：微软选择在浏览器里做这件事，其轻量化的技术路线与 DuckDB 系的思路是同构的——分析前移、平台后置，正在成为行业的共识方向（这是本文的归纳，非官方表述）。

第三件，分析就绪的 OpenStreetMap。这条最容易被忽略。开源地理数据的体量巨大，但从来都是“能用不好用”——格式杂、空间索引缺、分析门槛高。把它做“分析就绪”（analysis-ready），意味着开源社区正在把数据本身的加工也做掉，让引擎拿到数据的第一毫秒就能开始算。

三件事，分别对应格式、交互、数据三个层面，但指向同一个结果：传统湖仓平台作为“中间人”的价值区间，正在被从两头挤压。

👤 从库到产品，从代码到社区

月报还有两条值得单独一提：原生 Mac 应用，以及对 Mark Litwintschik 的社区聚焦。

原生 Mac 应用这个动作，很多人会觉得“不过是个客户端”。但换个角度看：DuckDB 此前的身份是库（library），是嵌进别人程序里的零件；做原生桌面应用，意味着社区开始直接面向终端用户交付完整产品。库变产品，意味着 UI、交互、更新通道、错误处理全套要补——这是商业化前的典型铺垫（属于本文的推测，社区并未官方确认商业化时间表）。MotherDuck 的云服务、引擎本身的原生应用、加上 AI 直连的入口，一条从单机到云、从人到 agent 的产品线已经隐约成形。

而社区聚焦 Mark Litwintschik，则是一个信号。他在 tech.marksblogg.com 上做数据工程基准测试多年，用大量真实数据集（包括著名的 11 亿条出租车行程数据集）逐一实测各类引擎，把原始耗时和硬件配置全部公开，是那种“用最笨的办法做最硬的验证”的深度用户。DuckDB 把聚光灯给他，而不是给某个明星创业公司，体现的是这个生态的价值观：性能是测出来的，不是发布会讲出来的。 这恰恰是工程文化对营销文化最有力的回应。

以下这张问题-方案卡，可以帮我们收拢全篇的判断：

小结：入口之战，才刚刚开始

把 2026 年 10 月月报里的七件事串起来看，DuckDB 生态正在做的事情可以用一句话概括：让引擎离数据和 AI 更近，让平台离入口更远。

2.0 的 PEG 解析器和异步 S3 读取，是在补引擎的硬实力；DuckLake 与 OneLake 的浏览器化，是在改写湖仓的交互与格式边界；Jev 的 AI 直连与原生 Mac 应用，则是在重新定义“谁拿着分析的入口”。

往前看，真正的悬念在于：当 agent 成为分析的主要调用方，付费的到底是算力还是席位？开放表格式之争会收敛还是分裂？单机引擎与分布式内核会不会在某个版本上合流？这些问题的答案，大概率不会出现在某场重磅发布会的主题演讲里，而是会像这份月报一样，安静地躺在某个周五的社区邮件中。

读数据基础设施的人，从现在起，也许该把生态月报加进必读清单了。

参考信源

• DuckDB 官方博客：duckdb.org/blog —— 2.0 版本发布说明、TPC-H SF3000 单机基准（"TPC-H at SF3000"）、解析器与文件系统相关技术文章
• DuckDB GitHub 仓库：github.com/duckdb/duckdb —— PEG parser 与异步 S3 读取对应的 PR、issue 与 release notes
• DuckLake 文档：ducklake.select —— DuckDB Labs 湖上表格式的设计与维护记录
• Mark Litwintschik 基准博客：tech.marksblogg.com —— 长期公开的引擎横向基准测试（含 11 亿条出租车行程数据集系列）
• Microsoft Fabric 官方更新：learn.microsoft.com/fabric —— OneLake 浏览器端能力公告

（注：本文中标注“观察”“推测”“观点”的段落，均为作者基于公开信息的判断，未经独立验证；基准数据的具体数值请以上述信源原文为准。）