DuckDB 2.0 存储格式换代

DuckDB 是一个嵌入式分析型数据库，默认以进程内方式运行，没有独立服务进程：数据放在一个文件或一块内存里，用列式引擎执行 SQL。2026 年 10 月 21 日，DuckDB 团队发布 2.0.0 LTS（代号 Cinnamon Teal，物种 Spatula cyanoptera），GitHub 发布页记录的时间是当天 12:49 UTC。这一版把新建库文件的默认存储格式换成版本 69，2.0 之前的 DuckDB 打不开这样的文件；官方给的社区支持期至少到 2027 年 10 月。

要点

支持期：发布博客写的是至少支持到 2027 年 10 月，发布日历上标的终止支持日期是 2027-10-22。上一个 LTS 1.4 在 2026-11-17 到期，1.5 被延长到 2027-03-01；发布日历上 2.0.1 计划在 2026-11-18 发布，日历注明日期可能推迟。
兼容性是单向的：2.0 新建的库文件用存储版本 69，1.x 写出的文件版本不高于 68。2.0 能读写旧文件并保留其存储版本，所以风险只出现在 2.0 新建或另存的文件上。
服务端模式：Quack 协议在 2026-05-12 公布，2.0 交付的是打磨版，新增 CONNECT 语句与 duckdb -serve、duckdb -connect 两个命令行入口；服务端默认只监听 localhost。

背景

DuckDB 官方把 1.0 的定位写成稳定性与向后兼容，2.0 首先是一个功能版本。这条线前面已经铺了几步：1.5 引入 VARIANT 类型，PEG 解析器在 1.5 里以可选功能出现。Quack 协议在 2026-05-12 公布，官方博客说它随 1.5.3 引入；5 月那篇公告写明，第一个生产版本会随 DuckDB v2.0 一起交付，2.0 兑现的就是这句话。

现在同时有三条维护线。2.0 是 LTS，1.4 撑到 2026 年 11 月，1.5 被延长维护到 2027 年 3 月，官方说这实际上也让 1.5 变成了一个 LTS 版本，目的是让升级方有足够时间测试。发布当天 CLI 与 Python 客户端已经可用，Go、R、Java 等客户端和部分扩展要等几天，官方给的原因是额外的改动与评审轮次。

代号有一处两种写法，别当成对不上。发布博客写的是 Cinnamon Teal，GitHub 发布页标题写的是 Cyanoptera，两者是同一个物种 Spatula cyanoptera，两个页面都点明了这一点。

背景里还有一件事需要分开看。InfoQ 10 月 17 日的报道写到 Amazon 已宣布收购 DuckLabs，DuckDB、DuckLake 与 Quack 继续以 MIT 许可开源，非营利的 DuckDB Foundation 继续监督项目。我们核对了 10 月 21 日的发布公告正文，其中没有出现 Amazon 或 AWS，所以这条不能写成「被收购后的首个版本」。

站内此前介绍过 MotherDuck 官方的 DuckDB MCP 服务（DuckDB / MotherDuck MCP），它让智能体用分析型 SQL 查本地文件、S3 或 MotherDuck 云。2.0 的 agent mode 处理同一类用法里命令行那一侧的输出问题，两者可以叠在一起用。

升级清单

2.0 的功能清单很长，官方博客按模块排列，几处对日常使用影响最大。性能上是 Parquet、CSV 与 DuckDB 原生格式的异步 I/O：读请求在后台发出，多条请求同时在途，I/O 层不再和查询层绑在一起，远程对象存储上的收益最明显。VARIANT 类型在 1.5 已经原生支持，2.0 的进展是把它完整接进执行与存储：官方原话是「DuckDB 1.5 already introduced VARIANT, but DuckDB 2.0 fully integrates it」，2.0 会识别数据里的公共结构并做 shredding，Parquet 的读写也走同一条流水线。

SQL 层新增了触发器，支持 BEFORE 与 AFTER、FOR EACH ROW 与 FOR EACH STATEMENT、通过 REFERENCING OLD/NEW TABLE 拿 transition table，被触发的表支持 RETURNING。官方也列了尚未支持的组合，例如 BEFORE 加 FOR EACH ROW、UPDATE 加 FOR EACH ROW。方言上还有一批补充：$variable 简写、在 CTE 里写 INSERT/UPDATE/DELETE/COPY、NEAREST 相似度连接、嵌套 schema。扩展侧可以自建仓库，仓库定义里钉住签名用的 RSA 公钥：按官方原文，在 CREATE EXTENSION REPOSITORY 时 DuckDB 抓取公钥并钉进仓库定义，同时打印每个公钥的 SHA-256 指纹供人工比对。C API v2 能力更强，官方明确说接口还没稳定，希望先有人试用。ICU 依赖被整个去掉，时区、日历与排序规则改由扩展自己实现，时区数据压缩到约 45 kB。提交数按发布稿的口径，是自 1.5 以来接近 2 万次。

破坏性变更不多，但每一条都会碰到具体部署：

变动	2.0 的行为	迁移动作
存储格式	新建库默认版本 69；1.5.6 只能读 64 到 68	需要老版本可读时显式指定存储版本（见下）
解析器	PEG 解析器成为默认	出问题时装 `legacy_parser` 扩展，执行 `SET enable_legacy_parser = true`
Lambda	单箭头 `x -> x + 1` 默认关闭	改用 `lambda x: x + 1`，或临时 `SET lambda_syntax = 'enable_single_arrow'`
编译器	自编译扩展需要 C++17	升级工具链
平台	社区扩展不再为 macOS x86_64 构建	2.1 停止支持 osx_amd64，提前迁到 arm64
构建	amalgamation 单文件构建弃用	改用常规构建
C API v2	能力更强，接口尚未稳定	先试用并回报问题

存储格式的退路写得比想象中具体。迁移文档给出的报错原文是 IO Error: Trying to read a database file with version number 69, but we can only read versions between 64 and 68. 要让老版本继续读，可以在建库时指定存储版本：命令行用 duckdb -storage-version v1.2.0 my_database.duckdb，SQL 里用 ATTACH 'file.db' (STORAGE_VERSION 'v1.2.0')，客户端也可以设 storage_compatibility_version。已有的库要转成 69，官方路径是用旧版本 EXPORT DATABASE 再用 2.0 IMPORT DATABASE。文档还提醒，多进程共用同一个库文件的部署里，只要有一个 2.0 进程写入了新格式，其余老进程就读不了，升级要整条链路一起走。

解析器的替换按官方说法应该无感：新解析器设计成与旧解析器兼容，解析不了的语句建议提 issue。单箭头 lambda 的开关只是临时桥，2.1 会把开关和语法一起删掉。

实测与争议

第三方实测目前只有预览版数据可用。LakehouseBox 的 Javier de la Torre 在 10 月 14 日发布了一组对 Apache Iceberg 的对比，被测版本是 2.0.0.dev2610011535，对照组是 1.5.6，同一份 TPC-H SF10 数据放在纽伦堡的对象存储上：

场景	1.5.6	2.0 预览版	结果
纽伦堡同机房冷跑（22 条查询）	105.9 s	62.7 s	总时长 1.69×，几何均值 1.93×
马德里家用光纤冷跑	270.8 s	260.3 s	1.04×
马德里热跑（同一连接重跑）	13.6 s	19.8 s	慢 46%，重拉 170 MB
Iceberg 写入 lineitem 6000 万行	409 个文件	4 个文件	8 表装载一起算，108.5 s 降到 84.6 s

数据中心的收益来自并发的小 range 请求：同样的字节量，HTTP GET 从 6,126 次涨到 9,346 次，延迟被重叠掉了。换成家用带宽，瓶颈回到链路，冷跑只快 4%；热跑反而慢了，原因是预览版在重复查询时又拉了 170 MB。作者还发现一个空间剪枝回归：按 Hilbert 曲线排过序的表，同一段 SQL 在 1.5.6 上读 9.4 MiB、发 8 次 GET，预览版却读了整张 281 MB 的表。他们 10 月 14 日报了 duckdb#27247，修复在 10 月 18 日合入 2.0 分支，10 月 20 日用新预览版复测，同一条查询读到 11.5 MiB、12 次 GET。作者写明这些数字来自预览构建，正式版还要重跑。

Hacker News 上的讨论能补充另一面。截至 2026-10-22 我们查看时，这条提交有 375 分、49 条评论。RobinL 说 2.0 在高核数 EC2 上快很多，读取和计算都快，核心利用率能顶到 128 到 192 vCPU，此前大约 64 vCPU 就到顶；他把 Splink 跑到 10 亿条记录、100 亿次比较，用时 10 分钟。同一个线程里他也提醒会「过度并行」：超过某个核数，墙钟时间反而变长。gopalv 把矛头指向 AWS Nitro，怀疑所有核同时忙时 CPU steal 升高。llimllib 提醒 duckdb-wasm 走 HTTP 做 range 查询时，如果不关掉 builtin_httpfs 会拉走大量数据；tomjakubowski 跟帖说，他正在查的 DuckLake 性能问题就是同一症状——read_parquet 会向 S3 发大量读取 footer 的小 range 请求。

InfoQ 在 8 月 25 日基于预览版做过一次架构解读，作者 Olimpiu Pop。文章描述的能力是客户端-服务端模式与挂载远程数据库：任何 DuckDB 实例可以当守护进程接网络连接，也可以 ATTACH PostgreSQL、MySQL 这类外部引擎并把查询下推过去；全文没有给出任何定量基准。那篇文章引用的「超过 1 万次提交」是 8 月预览稿的口径，10 月发布稿写的是接近 2 万次。

中文侧，QUASA 编辑团队 10 月 20 日的一篇分析没有提 2.0 或 LTS，但说清了选型边界：嵌入式 DuckDB 放进一个对外提供 API 的应用，仍要由应用自己安排并发请求、限制昂贵查询、处理写入与结果发布，查询量上来还要决定入口怎么扩容；单人 Notebook 的响应时间说明不了请求一起到来时的排队与尾延迟。

厂商自测数字另算。官方 10 月 16 日的博客用 TPC-H SF1000 测 NVIDIA Vera：88 核、单路的 Vera 综合分 3,073,292.99，对 96 核 Xeon 6 的 2,109,782.19，官方称领先 46%。这是一次未走官方审计流程的跑分，Vera 只用了单路，作者自己也只说是「有机会进入 SF1000 前三」。

编辑判断

对把 DuckDB 嵌在产品里、或者用它跑数据管道的团队，2.0 值得排进升级计划，前提是把存储格式当成一次真正的迁移来处理。单机升级本身不复杂，真正容易出事的是混版本部署：一个 2.0 进程写出的库，会让同目录下所有 1.x 进程一起读不了。要么整条链路一起升，要么在写共享库的地方固定 STORAGE_VERSION。官方的建议也罕见地直接：先在影子系统上测，关键业务可以等 11 月的第一个补丁版。

agent mode 的数字要按它测的东西读。59% 减少的是模型读到的 DuckDB 输出 token，在官方那次实验里从 123.6k 降到 50.8k；同一篇博客写得很清楚，这部分省下的量只占总输入的大约 0.5%，因为每一轮都要重读系统提示，运行时间与总成本没有明显变化，轮次还从 224 涨到 237。把 59% 当成「省一半成本」会读错。

Quack 转正改变的是部署形态，配套生态还在长。HN 上的 nicoritschel 说自己已经把 alpha 版放在生产里，当一个小组织的集中分析服务用；他同时指出 Quack 的客户端支持很有限，所以转头用 Postgres wire protocol 或 Arrow Flight 接现有 BI 工具。远程访问的安全默认值也保守：服务端只监听 localhost，allow_other_hostname 官方注明只用于测试，要跨机器就连 TLS 反向代理。

还没答案的部分：正式版 2.0.0 没有第三方基准，湖仓场景的预览数据全部来自 10 月中旬的构建，空间剪枝的修复也是刚合入。官方自测的 Vera 数字没有审计。要判断 2.0 在自家负载上的表现，只能自己跑一遍。

怎么试

最短的路径是装上 CLI，先确认版本，再试服务端与客户端一对：

curl https://install.duckdb.org | bash
duckdb -c "SELECT version();"

服务端开一个会话：

duckdb -serve

另一个终端连上去：

duckdb -connect

要让 2.0 写出的库还能被 1.5 打开，建库时把存储版本压回去：

duckdb -storage-version v1.5.6 legacy.duckdb

手动看 agent mode 的输出差异，加 -agent 即可；反过来用 -no-agent 关掉。没有设置任何 agent 环境变量的脚本，也可以靠 DUCKDB_AGENT_MODE=1 打开。

接下来

发布日历上 2.0.1 排在 2026-11-18，日历原文注明计划日期可能推迟，这也就是官方建议关键业务等待的那个补丁版。2.1 的删除清单已经写出来了：单箭头 lambda 与它的开关一起移除，macOS x86_64 停止支持。C API v2 要等一轮外部试用才谈稳定。LakehouseBox 说会在 2.0.0 正式版上重跑整套基准，包括修好剪枝之后的空间查询，那批数字出来才能判断预览版的结论还剩多少。