一只本地鸭子，开始抢数据平台的饭碗

DuckDB 2.0.0 LTS 来了。
代号 Cinnamon Teal，一只美洲西部的红棕色鸭。
听上去很可爱，干的事很猛。

这也是团队迄今最大的功能版本。
自 DuckDB 1.5 以来，接近 20000 次提交。
2.0 把 Quack 协议、异步 I/O、VARIANT、agent mode、触发器、可扩展 SQL 解析器一起推上台。

过去它是进程里的分析工具。
现在它想做服务器、湖仓入口、AI 代理的数据后端。

背景不复杂，野心很直白

DuckDB 团队宣布 2.0.0 LTS。
2.0 是长期支持版本，支持至少到 2027 年 10 月。
1.4 支持到 2026 年 11 月底。
1.5 被延长到 2027 年 3 月，实际上也成了一条 LTS 线。

1.0 时代，关键词是稳定和向后兼容。
2.0 时代，关键词是功能。

老实讲，这个转向很关键。
一个数据库一旦开始补协议、补触发器、补半结构化类型，它就不再只是工程师的瑞士军刀。
它会开始吃平台的活。

Quack 协议，把本地鸭子推上服务器

DuckDB 从第一天起就是 in-process 数据库。
1.5.3 引入 Quack 协议。
2.0 把它打磨成熟。

现在一个 DuckDB 进程可以把数据库 serve 出去。
另一个进程用 CONNECT 接入。
官方示例里，一条 ATTACH 加 CONNECT，就能切到远端库。

它还能连 PostgreSQL 和 MySQL。
新的 remote pushdown optimizer 会把查询直接推到远端服务器，而不是把表拉过来再算。

CLI 也加了 -serve 和 -connect。
命令行起服务，命令行连服务。

热门评论里有人说，DuckDB 能跑客户端服务器架构，是 game changer。

这话有点冲。
但个人觉得，方向确实变了。
以前大家问，DuckDB 能不能当中心化分析服务？
现在官方直接把门打开。

不过也别急着全换。
另一条热门评论提到，Quack 客户端支持现在还有限，不少工具更认 Postgres wire protocol 或 Arrow Flight。
所以这扇门开了，生态还得追。

异步 I/O，让远端存储不再拖后腿

2.0 给 Parquet、CSV 和 DuckDB 原生存储加了异步 I/O。
I/O 层和查询处理层分开扩展。
读取在后台发起，多个请求同时挂着。

这对对象存储很关键。
查 s3:// 数据，最怕网络等待。
现在并行度更高，查询更快。

有用户在热门评论里转述，2.0 在 EC2 高核机器上快得多，过去大约 64 vCPU 就封顶，现在能推到 128 甚至 192 vCPU。

这不是官方跑分。
但评论区给出这种体感，说明异步 I/O 和高核机器确实碰出了火花。

说实话，分析数据库卷到最后，很多时候是 I/O 先趴下。
DuckDB 这次把读数据这件事往前挪了一步。

VARIANT，让 JSON 不再像文本包袱

DuckDB 1.5 已经有 VARIANT。
2.0 把它做成一等公民。

官方把它叫 JSON on steroids。
VARIANT 可以存每行形状不同的半结构化数据。
但它不是纯文本。

2.0 会检测数据里的公共结构，然后 shred。
结构被拆开，压缩更好，执行更快。
Parquet 的读写也打通，还配了 variant_* 函数。

这很实用。
日志、事件、用户行为、API payload，本来就乱。
以前塞 JSON，查询像拆盲盒。
现在 DuckDB 想把半结构化数据拉回列式执行的主赛道。

Agent mode，AI 代理成了新用户

最有意思的一块，是 agent mode。

Claude Code、Codex、Cursor 这类编码代理，越来越多地替用户操作 DuckDB CLI。
2.0 的 CLI 会检测自己是不是被 agent 运行。
如果是，就切到 agent mode。

输出从 padded boxes 变成紧凑 Markdown 表格。
结果被截断会明确说明。
失控查询会提前停掉。
错误以 JSON 返回。
长查询还会先报预期成本，让 agent 决定要不要等。

官方在 TPC-H 实验里说，agent mode 把模型要读的 DuckDB 输出减少了 59%。

这点我挺认同。
数据库过去默认用户是人。
现在模型也成了用户。
模型不需要漂亮边框。
模型需要少废话、可解析、能止损。

谁先把 AI 代理伺候舒服，谁就更容易进入自动化工作流。

PEG 解析器，SQL 语法开始可插拔

DuckDB 以前用从 PostgreSQL 衍生来的解析器。
2.0 把自研 PEG 解析器设为默认。

旧解析器从 2018 年第一次提交就在了。
YACC/Bison 生成 LALR(1) 解析器。
SQL 方言越大，越容易撞规则。
小改动也可能引发 shift/reduce 或 reduce/reduce 冲突。

PEG 按书写顺序尝试备选路径。
加语法不容易破坏无关规则。
Python 3.9 也走过类似路线。

扩展还能挂进语法本身。
以后可能出现全新 SQL 语法的扩展。
错误信息也带精确位置。

对普通用户，切换应该无感。
官方也说有问题可以临时切回旧解析器。
但对扩展生态，这是一把新钥匙。

触发器上线，DuckDB 的味道变了

2.0 交付了触发器。
CREATE TRIGGER 支持 BEFORE 和 AFTER。
支持 FOR EACH ROW 和 FOR EACH STATEMENT。
支持 transition tables。
支持多个触发器、RETURNING、DROP TRIGGER。

经典场景是审计表。
目标表一改，触发器记录变化。

更值得注意的是，触发器还能增量维护物化视图。
官方给了一个例子，用 insert 和 delete 两个触发器维护每个国籍的平均年龄。

热门评论里有人说，触发器让人兴奋，DuckDB 真的接近 data warehouse in a box。

这话有情绪，但不空。
触发器、半结构化、远端连接、湖仓扩展放在一起，DuckDB 确实越来越像一个可随身携带的分析平台。

当然，官方也写明部分组合还不支持。
比如某些 BEFORE ... FOR EACH ROW 和 UPDATE ... FOR EACH ROW 的组合。
别把它当成已经完全成熟的企业数仓。

扩展生态，正在往企业场景补

2.0 还带来 C API v2。
官方说它比上一代强得多，能把文件系统和表函数暴露给扩展。
目前希望社区先试用，再反馈。

扩展仓库也来了。
组织可以托管自己的可信扩展仓库。
用 RSA 公钥签名，像内置扩展一样安装和加载。
仓库前缀可以指向本地路径、https、s3。

核心扩展也在推进。
DuckLake 1.1 发布。
Iceberg 扩展朝功能完整推进，加入 REST catalog 的 ATTACH 选项。
Delta 扩展支持 CREATE TABLE、分区、表属性、时间旅行，并改进 VARIANT 支持。

这些词放在一起，意思很清楚。
DuckDB 想接住湖仓，也想接住企业内部扩展治理。

真正该警惕的，是升级成本

功能很猛。
坑也摆在明面。

最要注意的是存储格式。
DuckDB 2.0 之前的版本，读不了 2.0 创建的数据库文件。
2.0 可以读写旧文件。
官方建议先在影子系统测试，再切生产。
关键负载可以等 11 月第一个补丁。

编译要求也变了。
DuckDB 2.0 需要 C++17 编译器。
发布构建默认切到 Clang。

ICU 库被移除。
时区、日历、排序规则由 icu 扩展自己实现。
IANA 时区数据压缩到约 45 kB。
官方说行为保持一致，原生实现还更快。

旧单箭头 lambda 语法默认关闭。
要改用 Python 风格语法。
amalgamation 构建被弃用。
osx_amd64 也在逐步退出，2.1 将停止支持。

这些变化不算戏剧化。
但足够让复杂部署慢下来。
大版本最迷人的地方是功能，最折磨人的地方是迁移。

DuckDB 2.0 把原本偏嵌入、偏本地、偏单进程的工具，推向更宽的分析场景。
当一只本地鸭子开始干服务器、湖仓和 AI 数据后端的活，传统分析栈会被压缩吗？

【锐评】：DuckDB 2.0 最狠的地方，是把嵌入式数据库写出了平台野心，升级坑也同样真实。

参考链接：
https://duckdb.org/2026/10/21/announcing-duckdb-200