DuckDB 2.0 来了：进程内数据库的「出圈」时刻
DuckDB 2.0 LTS「Cinnamon Teal」发布：Quack 协议让进程内数据库当服务器使，异步 I/O 吃满 192 核，VARIANT 给 JSON 装上列式引擎，CLI 还学会了认出调用者是 AI。本期访谈聊聊一个「库」是怎么一步步长成「仓库盒子」的。
这周数据圈最热闹的事：DuckDB 发布了 2.0 LTS，代号「Cinnamon Teal」（一种红褐色的鸭子）。官方说这是迄今最大的功能版本——1.0 讲的是稳定和向后兼容，2.0 全是新东西：打磨过的 Quack 客户端-服务器协议、异步 I/O、一等公民的 VARIANT 类型、Agent 模式、触发器、可扩展的 SQL 解析器，背后是 2 万多次提交。LTS 支持到 2027 年 10 月。HN 讨论里有人直接放话：这会替代很多重型数据栈；也有人当场泼冷水。我请来老朋友陆骁——在一家出海 SaaS 做数据平台，公司的嵌入式分析和日志管线都跑在 DuckDB 上——聊聊一个「库」是怎么一步步「出圈」的。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 骁哥，先问第一反应。DuckDB 2.0 这次，你觉得哪个变化最值得普通开发者抬头看一眼？
陆骁： 一句话：它不想只当「库」了。DuckDB 从第一天起就是进程内数据库，你 import 它，它在你进程里跑。这次 2.0 把 Quack 协议打磨成了正式功能——任何 DuckDB 进程都能 serve 自己的数据库，配上新的 CONNECT 语句，一条命令就能连上远端库、切换会话。CLI 甚至加了 -serve 和 -connect 参数。这意味着你手里那个轻量到可以塞进二进制的引擎，突然也能当服务器使了。
小听： 评论区最高亮的回复之一就是这个：「game changer，会替代很多现在跑在多台服务器上的数据栈」。但紧接着就有人泼冷水：Quack 的客户端支持现在还很少，他自己写了个扩展走 Postgres 协议曲线救国。这两拨人谁对？
陆骁： 都对，这恰恰是 DuckDB 聪明的地方。协议是基础设施，生态跟上需要时间——新协议刚发布，BI 工具、驱动都不认它，泼冷水那位说的是现实。但「game changer」那派看到的是另一层：以前你要做集中式分析，要么起一套重型数仓，要么每个节点各跑各的；现在一个轻量进程就能 serve，数据栈的「起步重量」被压到了地板。更妙的是 CONNECT 不只认 Quack，还能连 Postgres、MySQL，并且把查询下推到远端执行——它不逼你二选一，先把你现有的东西接进来。
库可以很小，野心可以很大。
小听： 再往下看是异步 I/O。评论区有人认真发问：给 CSV 和 Parquet 做异步读，好处到底在哪？这问题问得挺实在的。
陆骁： 问到了点子上。关键不在于「异步」这个词时髦，而在于把 I/O 层和计算层解耦了。以前读文件是计算线程顺手干的活，读的时候算力在等；现在 I/O 自己在后台发请求、同时在途好几个，算力只管算。对本地 SSD 可能感知不强，但一旦读的是 s3:// 这种对象存储，网络延迟就被藏起来了，吞吐直接拉满。HN 上有个生产用户实测：2.0 在高核数 EC2 上能把 128 核甚至 192 核吃满，以前 64 核就到顶了。做日志分析、ETL 的人，这个数字比任何新语法都实在。
小听： VARIANT 类型呢？官方说法是「JSON on steroids」，1.5 就引入了，2.0 算正式转正。
陆骁： 对，半结构化数据这个老大难。以前你要么把 JSON 当文本存、查询时现解析，要么提前定死 schema。VARIANT 的做法是：每行可以形状各异，但引擎会去探测数据里的公共结构，做「shredding」拆解——存得下、压得住，执行还是列式的速度，Parquet 读写也打通了，还配了一整套 variant_* 函数。对我们这种日志字段天天变的花活场景，这就是「既要又要」的答案。
小听： 聊到这儿必须问本期我最感兴趣的：Agent 模式。CLI 能检测出调用者是 AI Agent，然后切换输出风格——紧凑的 Markdown 表格、明确告诉你结果被截断了、提前掐掉失控查询、报错走 JSON，长查询还先报成本。官方说在 TPC-H 上，模型要读的输出量少了 59%。
陆骁： 这是 2.0 里信号量最强的一个变化，很多人低估了它。以前所有 CLI 都是给人看的：漂亮的框线表格、对齐的列。现在调用者有一半是 Agent——Claude Code、Cursor 们天天替用户驱动 DuckDB CLI。Agent 不需要框线，需要的是「别浪费我的 token、别让我猜」。59% 这个数字翻译一下：同样的分析任务，模型上下文省了一多半，出错率还降了。以后 CLI 工具的第一个问题可能不再是「人怎么看得爽」，而是「调用者是谁」。
小听： 评论区还有人说，DuckDB 2.0 加了触发器之后，「真的快成一个盒子里的数仓了」。触发器这种上古功能，值得这么兴奋吗？
陆骁： 值得，因为补上了「仓库盒子」的最后一块拼图。CREATE TRIGGER 支持 BEFORE/AFTER、FOR EACH ROW/STATEMENT，还有 REFERENCING OLD/NEW TABLE 这种过渡表——经典用法是审计表：数据一改，自动记一笔「谁改了什么」。更狠的是能拿它做增量物化视图：官方示例里用两个触发器维护「各国平均年龄」，插入加、删除减，不用再全量重算。当然有些组合还不支持，比如 BEFORE FOR EACH ROW，但方向很清楚：以前 DuckDB 是分析引擎，现在它想把「管数据的活」也接过来。
先认出调用者是谁，再决定怎么说话。
小听： 还有个容易被忽略的：解析器换了。从 PostgreSQL 派生的老解析器，换成了自研的 PEG 解析器，扩展甚至能 hook 进语法本身。
陆骁： 对，而且有个很妙的参照：Python 3.9 干过一模一样的事。老解析器是 YACC/Bison 生成的 LALR(1)，DuckDB 的 SQL 方言越长越大，加一条新语法都可能和旧规则撞车，shift/reduce 冲突防不胜防。PEG 按书写顺序试 alternative，加语法不再有「牵一发而动全身」的风险。对普通用户最直接的体感是报错信息带上了精确源码位置；对生态的意义是：以后可能出现带全新 SQL 语法的扩展。解析器这种基础设施，换一次管十年。
小听： 时间线上有个巧合：同一天 HN 首页还有一条 PyPI 供应链投毒的新闻（LiteLLM 被植入窃密后门）。而 DuckDB 2.0 恰好推出了「扩展仓库」——允许企业自建、自签名的扩展源。这两者放一起看，有点意思。
陆骁： 太有意思了，简直是同一枚硬币的两面。DuckDB 的扩展以前只能从官方源装，现在企业可以 CREATE EXTENSION REPOSITORY 自建源、用自己的 RSA 密钥签名，安装时还会打印密钥指纹让你核对。翻译成大白话：扩展的信任链从「信官方」变成了「信你自己的签名」。在供应链攻击越来越频繁的今天，官方这是在把「可验证的信任」做成基础设施，而不是靠运气。
小听： 最后聊聊 LTS。这次 1.4 支持到今年 11 月，2.0 支持到 2027 年 10 月，连 1.5 都被延长到了 2027 年 3 月。对国内想上生产的团队，你的建议是？
陆骁： 两条。第一，LTS 线敢跟：DuckDB 的 LTS 不是摆设，1.0 那次就证明了他们的兼容性承诺是认真的，这次三线并行、过渡期给足，说明团队知道生产环境最怕什么——不是没新功能，是升级心惊胆战。第二，别把它只当「分析引擎」用：日志压缩归档、ETL 胶水、嵌入式报表、Agent 的 SQL 沙盒，这些场景它现在都是第一梯队。HN 上那位老哥用 2.0 把 7TB 的 Azure 日志压到 2.5% 存成 Parquet、直接对着对象存储做即席查询，连 Splunk 都省了——这才是 DuckDB 真正的打开方式：不是去替代你的数仓，而是去吃掉那些「不值得起一个数仓」的活。本文观点仅代表访谈角色设定，原始讨论见参考链接。