DuckDB 周报：双版本齐发，内部原理炸翻 HN，pg_ducklake 1.0 来了

2026.06.14 — 2026.06.21

这周如果你打开 Hacker News，会看到一条 460 分的帖子挂在首页——不是新功能发布，不是融资新闻，而是一篇 DuckDB 内部原理的深度解析。

评论区像开了闸。有人说"2026 年我用得最多的工具就是 DuckDB"，有人分享在 AWS 上跑 DuckDB 时发现 GP3 磁盘吞吐默认只有 125MB/s 导致性能打骨折，有人讲怎么用 DuckDB 查全公司工程师的 Claude Code 会话日志来量化研发效能。

一篇讲"数据库为什么快"的技术文章，炸出了这么多真实的生产故事。这本身就是 DuckDB 当下的一个注脚：它已经从"笔记本里的轻量分析工具"变成了一线工程师手中不可替代的瑞士军刀。

而在同一天，DuckDB 团队悄悄发了两个版本。

section-header

● ● ●

双版本发布：v1.5.4 + v1.4.5 LTS

6 月 17 日，DuckDB 同时释出了 v1.5.4（Variegata）和 v1.4.5 LTS（Andium）。官方自己都调侃版本号有点让人迷惑，但规则其实很简单：v1.5.x 是当前最新稳定线，v1.4.x 是长期支持线。

v1.5.4 是一个 bugfix + 性能补丁版本，但这次的修复列表有几个值得关注的条目：

正确性修复

• VARIANT 类型在过滤条件下读取错误行的 bug（#23031）——如果你在用 VARIANT 做 JSON 分析，这次升级很关键
• MERGE INTO 中 WHEN NOT MATCHED 和 WHEN NOT MATCHED BY TARGET 绑定逻辑修正（#23014）
• INSERT … SELECT ON CONFLICT 中列名大小写匹配问题（#22825）

崩溃修复

• 修复了通过管道输入 SQL 时进度条输出异常和崩溃（#22836）
• gzip 压缩写入溢出修复（#23232）
• UNPIVOT 中绑定不存在表达式时的崩溃保护（#23156）

性能改进

• jemalloc 构建下系统堆内存裁剪（#23253）——长时运行的 DuckDB 实例终于不会一直抱着不用的内存不放了
• 原生 Geometry 类型的 Parquet 统计剪枝优化，新增 Parquet reader 的 OPERATOR_ROW_GROUPS_SCANNED 指标（#23140）

CLI 体验

• 新增 -dark-mode 和 -light-mode 显式选项，改进了终端背景色自动检测（#23246）
• 实验性的 vacuum_rebuild_indexes ATTACH 选项（#22690）

官方在公告末尾扔了一个 hook：v2.0.0 预计今年秋季发布。下周三（6 月 24 日）的 DuckCon #7 上，大概率会有更多细节。

section-header

● ● ●

460 分：一篇内部原理文章点燃 HN

Greybeam 的 Kyle Cheung 写了一篇《DuckDB Internals: Why is DuckDB Fast? (Part 1)》，5 月发在自家博客上，这周被人贴到 HN 后直接炸了。

文章从 SQL 文本进入引擎开始，讲到解析、绑定、优化、物理计划、存储层，把 DuckDB 快的原因拆成了几个核心设计选择：

进程内执行。DuckDB 不是一个服务器，是一个库。没有 TCP 连接、没有序列化/反序列化开销。在最好的情况下（比如查询 Pandas DataFrame），可以达到零拷贝——直接读 Python 进程已经持有的内存缓冲区。

列式存储 + Zone Map。每列拆成行组（最多 122,880 行），每个行组携带 min/max/null-count 元数据。WHERE 过滤时先查 zone map，不符合条件的行组直接跳过，磁盘读都不读。这和 Snowflake 的 micro-partition pruning、BigQuery 的 block pruning 是同一种思路。

向量化 + Morsel 并行。查询计划被拆成 pipeline，每个 pipeline 在所有核心上并行跑，每个线程处理自己的 morsel（2048 行的批次）。Pipeline 之间的断点（GROUP BY、ORDER BY、hash join 的 build 端）用三段式（sink/combine/finalize）处理，combine 阶段也是并行的。

30+ 优化器 passes。从 filter pushdown 到 join order optimization（DPhyp/DPccp 动态规划），整个优化阶段通常在 1 毫秒内完成。可以用 SET disabled_optimizers = 'filter_pullup, join_order' 单独关掉某个 pass 来调试。

评论区比文章本身还精彩：

"我是做税务分析的，数据量大得离谱。我们在 AWS 上用 GP3 磁盘跑 DuckDB，一开始性能不对，后来发现 GP3 默认吞吐只有 125MB/s——调完之后，起飞。"

"我花了一周折腾 Redshift、Athena、Glue，做出来的 PoC 又脆又慢又贵。换成 DuckDB，不到一天全搞定了。快到我怀疑自己是不是漏了什么。没漏。"

"DuckDB 正在变成各种数据生态之间的超级胶水——GIS、可观测性、分析、lakehouse、对象存储，这些东西本来不互相说话，DuckDB 把它们粘在了一起。"

section-header

● ● ●

pg_ducklake 1.0：PostgreSQL 的 DuckLake 快车道

同日发布的还有 pg_ducklake v1.0。这个 PostgreSQL 扩展允许从 PG 直接把数据高速摄入 DuckLake lakehouse 格式。

三个关键点：

• 生产就绪：从今年 1 月起步，先是 pg_duckdb 的 fork，3 月变成独立扩展，6 月 17 日发布 1.0
• 最快的摄入路径：官方宣称是"从 PostgreSQL 到 lakehouse 的最快数据摄入方式"
• 可复用内核：架构上把核心逻辑抽成了可复用的 kernel，意味着未来可能扩展到更多场景

对于已经在用 PostgreSQL 做事务处理、又想把分析负载卸载到 DuckDB/DuckLake 的团队来说，这个扩展填了一个关键的坑——不用再自己写管道搬数据了。

section-header

● ● ●

社区速览

cargo-duckdb-ext-tools v0.5.0：用 Rust 写 DuckDB 扩展，现在只需要 4 条命令。cargo install cargo-duckdb-ext-tools && cargo duckdb-ext-tools new my_ext && cargo duckdb-ext-tools build && cargo duckdb-ext-tools test。如果你曾被 DuckDB 扩展的 ABI flag 和打包细节折磨过，这个工具可以让你回到正常的 Rust 开发体验。

duck_diff 扩展：社区扩展仓库新提交了一个 diff 扩展（#2051），6 月 12 日开 PR，18 日还在活跃更新。能在 DuckDB 里直接做数据 diff。

DuckDB's Agent Moment：dbt 的 Analytics Engineering Podcast 新一季主题是"Analytics × Agents"。MotherDuck CEO Jordan Tigani 在 6 月 18 日的节目里聊了为什么 DuckDB 是 AI Agent 的理想数据库——in-process、零配置、SQL 原生、LLM 友好。

section-header

● ● ●

下周预告

• 6 月 23 日：法国 CASD 数据技术研讨会，DuckDB 专场
• 6 月 24 日：DuckCon #7 阿姆斯特丹。Hannes Mühleisen 和 Mark Raasveldt 的 State of the Duck 主题演讲；议程包括 PySpark→DuckDB 迁移、Spotify 的 Agent SQL 层、癌症基因组学、能源政策分析、拉力赛遥测等案例。线上线下同步。

本週报由 Hermes Agent 自动生成，每周日推送。如有新闻线索，欢迎通过公众号留言。