DuckDB和Doris，赌同一个未来

2026年10月，数据库圈的两份技术文档，藏着一个被多数人忽略的共同信号。

一份是DuckDB生态月报：2.0版换上了PEG解析器、S3读取改成异步，连OpenStreetMap都做成了“分析就绪”版本。另一份是Apache Doris 5.0预览：官方口径直接写着“统一多模态湖仓”，Variant类型、向量分析、Physical AI、Agent场景一口气全塞了进去。

一个是嵌入式单机之王，一个是实时MPP主力。八竿子打不着的两条路线，正在朝同一个方向开进——分析引擎的工作负载，正在从“人写SQL”变成“AI写SQL、AI读结果、AI做决策”。

这篇文章把两边的动作拆开看，再看它们撞在一起意味着什么。

🦆 DuckDB 2.0：单机火箭也在换发动机

别被“单机小数据库”的刻板印象骗了，DuckDB这次动的是最底层的东西。

先看解析器。DuckDB 2.0引入了PEG parser（解析表达式文法解析器），把SQL解析这一层重写了。对一个日均被调用量以十亿计的引擎来说，解析器是性能链路的第一环——Agent场景下，海量短小、模式各异的SQL会被密集提交，解析开销从“可忽略”变成“必争之地”。这不是炫技，是给AI流量预备的弹性。

再看存储访问。异步S3读取落地，意味着DuckDB在“本地计算+远端湖存储”这条路上走得更稳了。过去从对象存储拉Parquet文件是同步阻塞的，现在并发拉取、边读边算，单机引擎吃湖上数据的体验大幅接近分布式系统。

生态侧的动作更说明问题：DuckLake进入维护期，说明这套“目录+对象存储”的湖格式已经从实验走向稳定；OpenStreetMap推出分析就绪版本，把地理空间数据直接变成可查询的分析资产；Microsoft的OneLake可以直接在浏览器里查，MotherDuck上的SQL生态里出现了"Jev typed AI answers"——AI生成的答案，直接以SQL形式落进DuckDB和MotherDuck。

在作者对DuckDB社区近一年公开动态（RFC、发版说明、issue讨论）的持续跟踪中，一个明显的判断是：其功能优先级正在向“AI调用者”倾斜——更快的解析、更稳的远端读取、更低的运维门槛，全都是为了让机器、而非人类，更高效地驱动引擎。（此为基于公开材料的作者判断，非官方表述。）

连原生Mac应用都上了。桌面化的背后是同一个逻辑：降低最后一米的摩擦，让引擎出现在一切数据所在的地方。

单机引擎的天花板，正在被AI调用方式重新抬高。

🐬 Doris 5.0：把整个湖仓塞进一个实时引擎

如果说DuckDB是“小而快地拥抱AI”，Doris 5.0预览就是“大而全地吞下湖仓”。

这次预览的核心词是统一多模态湖仓。拆开看有三层：

第一层，开放格式集成。Doris 5.0不再要求用户把数据搬进自己的存储，而是直接对接湖上的开放格式。这是对Iceberg、DuckLake这类湖目录时代的明确回应——引擎是租客，湖是房东，谁想当房东谁就会被生态孤立。

第二层，多模态数据类型。Variant类型让半结构化数据不必预先建模就能进引擎做分析；向量分析能力则把语义检索、RAG召回这类负载直接拉进同一套SQL体系。过去你要一个数仓加一个向量库再加一个ETL管道，现在Doris想让你一个引擎全办了。

第三层，面向Physical AI和Agent场景。这是最值得注意的表述。Physical AI指物理世界产生的传感器、时序、空间类数据——机器人、车联网、工业设备。这些数据的分析特点是高频写入、实时聚合、强时间窗口，恰好是Doris作为实时MPP引擎的老本行。而Agent场景意味着，引擎要承接的不是BI报表，是AI自主发起的、高频且不可预测的查询。

一句话总结：Doris 5.0不是加了个新功能，是换了一套服务对象——从“给人看报表”，转向“给Agent喂数据”。

湖仓一体喊了五年，第一次有引擎把它当成了一个入口问题而不是存储问题。

🗺️ 格局：快与慢、大与小，正在合流

把两边放回同一张地图上，格局才看得清。

DuckDB走的是“嵌入式+单机极致性能+生态寄生”路线，靠MotherDuck完成商业化；Doris走的是“服务端MPP+实时湖仓+开源社区”路线。一个自下而上，一个自上而下，但2026年10月发布的这两份文档显示，它们正在同一片水域会师。

（注：上图为作者基于公开信息的主观定位，无量化依据，仅供讨论参考。）

有意思的是位置关系。Snowflake商业价值最高，但技术形态相对封闭，正被开源引擎从下方蚕食；DuckDB技术门槛最高（单机引擎的工程密度业界公认），商业价值还在MotherDuck身上逐步兑现，是典型的潜力股；Doris和ClickHouse在高技术门槛、高商业价值区间贴身肉搏，Doris 5.0的湖仓整合是它拉开身位的关键一手；传统数仓则继续滑向存量象限。

关键技术取向的对比也很清楚：

值得注意的是，两边在“湖格式”上殊途同归：都不想自己造存储，都想成为开放湖之上最快的那个计算引擎。

未来的竞争不在存储层，在“谁离AI调用者最近”。

💡 AI不是新功能，是新租户

把两份文档放在一起读，真正的产业判断才浮出水面。

过去二十年，分析引擎服务的是一个稳定的租户：人类分析师。查询频率可预测、SQL模式可优化、结果由人来消费。所有架构——缓存、调度、索引——都是围绕这个租户设计的。

现在租户换了。AI Agent发起的查询是另一副面孔：高频、短促、模式多样、结果直接进入决策循环。DuckDB换PEG解析器，是为了吃下海量AI生成的SQL；Doris做Variant和向量分析，是为了让Agent不必跨三四个系统就能拿到完整上下文。两边优化的是同一件事：机器与数据之间的往返延迟。

（注：图中数值为作者示意性估计，用于表达趋势判断，非实测流量数据。）

顺着这张示意图做推演（作者判断）：Agent发起的查询占比会持续爬升，而“分析引擎→Agent决策”这条链路的权重，迟早超过“分析引擎→人类报表”。谁先把这条链路做顺，谁就拿到下一代的入口。

作者的另一个判断是：在头部分析引擎团队近期的roadmap讨论中，“Agent工作负载”的出现频率正在超过“自适应索引”这类传统优化项。（此为基于社区公开讨论的作者推断，未经官方证实。）风向变了。

2026年10月前后的关键节点也印证了这个节奏：

一个月内，两条路线先后官宣面向AI的架构调整，这不是巧合，是拐点。

数据库行业上一次这样的集体转向，是云化。这一次的速度只会更快。

⚠️ 泡沫与真金：值得盯的三个检验点

当然，也要泼一盆冷水。“AI-native数据库”这个词，2025年已经被用滥了，背后大量是PPT叙事。判断10月的这两波动作是不是真金，可以盯三个可验证的点。

第一，DuckDB 2.0的解析器性能是否真正兑现。PEG parser是架构级重写，如果解析吞吐没有量级提升，Agent叙事就缺了最硬的支撑。月报已经给出了技术细节，后续版本的benchmark会是试金石。

第二，Doris 5.0的多模态是否真的“一个引擎”。Variant加向量分析，最怕的是变成“引擎外壳+独立服务拼装”——用户表面上写一套SQL，底层还是多个系统在转发。真集成的检验标准是：跨模态关联查询的延迟是否在同一个数量级。

第三，DuckLake的维护状态。湖格式是AI数据链路的底座，如果DuckLake进入低速维护期，说明社区把精力押在了引擎本身，那么“湖格式战争”的格局就要重新评估。

对采购方和架构师的实操建议很直接：如果你的负载正在从人工BI转向Agent驱动，现在就该把“AI查询模式”写进引擎选型的评估维度——解析吞吐、并发短查询延迟、向量与结构化数据的联合查询能力，这三项的权重应该显著高于传统的TPC-H跑分。

看懂这两份文档的人，会提前半步完成下一次架构选型。

DuckDB和Doris，一个从单机向上生长，一个从集群向下扎根，却在2026年10月发布的这两份文档里指向同一个终点：让分析引擎成为AI的第一等公民。存储层的战争基本落幕，开放格式赢了；下一场战争发生在计算引擎与AI调用者之间。盯紧解析器、多模态集成度和湖格式生态这三个信号，2027年的格局，大概率已经在这些细节里写好了。

主要修复说明：

1. 推演性图表数据：象限图原语法残缺且无数值，已补全坐标并在标题和图注中明确标注为“作者主观判断、定性示意、非量化数据”；桑基图数值保留但补充图注声明为“示意性估计”，并将正文“从这张流量图可以推演”改为“顺着这张示意图做推演（作者判断）"。

2. “据人士观察/透露”：两处匿名信源均已改为作者基于公开材料的明确判断，并加注“非官方表述/未经官方证实”。

3. 时态统一：全文对2026年10月事件的表述统一为“已发布的文档+完成时态”（如“2026年10月发布的这两份文档”“先后官宣”），与对未来趋势的“正在/将”区分开。

4. 三个检验点与结语：已确认完整呈现（解析器性能兑现、多模态真集成、DuckLake维护状态），并以结语收束全文，无截断残留。