DuckDB新版本发布，求求你给友商留条活路吧
digoal约 7 分钟本期播客
DuckDB, 求求你给别的数据库留条活路吧
DuckDB 1.5.1 发布, 又暴露了它的野心, 只看2个新增的功能即可.
这话我1年多前说过, 不知道你记不记得, 我帮你回忆回忆: DuckDB 暴露野心，日后与PG必有一战
你以为 DuckDB 还只是个“查 Parquet 很快的小数据库”？
错了。
DuckDB 1.5.1 真正释放的信号，是它开始同时往两端吃：一端吃 AI 数据底座，一端吃开放湖仓执行层。 官方这次在 1.5.1 里明确加入了 Lance format 支持，同时继续扩展 Iceberg v3 支持。这不是普通功能迭代，而是在公开宣告自己的版图： 既要进 AI/向量/多模态数据场景，也要进企业级湖仓读写协同场景。
先说结论：DuckDB 的野心，已经不是“轻量数据库”
这次更新最值得重视的，不是 patch release 这几个字，而是它押中的两个格式：
Lance：更贴近 AI/ML 工作负载的数据格式 Iceberg v3：更贴近企业级开放表格式、湖仓治理和演进能力的底座
官方在 1.5.1 发布中写得很清楚：这次版本包含对 Lance lakehouse format 的支持，并继续扩展 Iceberg v3，包括 VARIANT、TIMESTAMP_NS、默认值、deletion vectors、分区表插入与创建等能力。
一句话翻译成人话就是：
DuckDB 不满足于做“文件查询器”，它想成为一个同时理解 AI 数据和湖仓数据的通用执行层。
这才是这次更新真正该被放大的地方。
为什么 Lance format 值得你高度关注？
因为 AI 场景最缺的，不是模型，而是“能被高效消费的数据格式”
DuckDB 文档对 Lance 的定义很直接：
Lance 是一种面向 ML/AI 工作负载优化的现代 lakehouse format，并且原生支持云存储。 DuckDB 现在已经能通过 lance 核心扩展直接读写 Lance 数据集。
这句话的含金量非常高。
过去很多团队做 AI 数据链路时，常见问题不是“有没有数据”，而是：
向量、文本、结构化元数据分散在不同系统里 训练、检索、标注、评估的数据格式不统一 对象存储里文件很多，但真正查起来很别扭 数据科学、工程、应用三拨人用的工具完全不同
而 Lance 这类格式的价值，本质上是在解决一个更底层的问题：
让 AI 数据既能存，又能查，还能把向量检索、全文检索、混合检索这类能力一起纳进来。
DuckDB 对 Lance 的支持，不只是“能读个新文件”。官方文档已经展示了几类关键能力：
直接查询本地或 S3 上的 .lance数据集直接把 DuckDB 查询结果 COPY到 Lance通过 ATTACH目录作为 Lance namespace 来建表支持 vector search 支持 full-text search 支持 hybrid search（向量 + 文本）
这意味着什么？
意味着 DuckDB 不是只想在 AI 链路里当一个“旁观者 SQL 引擎”，它是在争夺一个更关键的位置：
AI 数据进入应用之前的那层可执行接口。
Lance 的典型场景，不是“替代数据库”，而是打通 AI 数据闭环
如果你是 DBA 或架构师，先别急着问“Lance 能不能替代 XXX”。真正该问的是：
哪些 AI 数据链路，正在因为格式割裂和工具割裂，导致成本畸高？
Lance 更适合的场景，通常有这几类：
场景一：向量检索 + 结构化过滤
很多 RAG、推荐、语义搜索场景，不是单纯做 ANN 检索，而是“先筛一批业务条件，再做向量近邻”。DuckDB 现在能直接对 Lance 做向量搜索，还能继续用 SQL 做过滤和分析，这种组合非常适合应用内检索和离线评估。
场景二：文本检索 + 向量检索混合召回
官方文档直接给了 FTS 和 hybrid search 的接口。现实世界里，很多查询只做向量并不稳，词法相关性、关键词命中、业务字段约束都很重要。能把这几种能力收敛到一个可嵌入执行层里，工程复杂度会下降一大截。
场景三：训练集、评测集、推理样本的一体化管理
当你把查询结果直接写成 Lance，甚至把目录 attach 成 namespace 来管理时，DuckDB 就不只是消费端，它开始进入“组织数据资产”的位置。对 AI 团队来说，这比“多一个格式支持”更重要，因为这决定了训练、评测、上线三段数据链路能不能统一。
再看 Iceberg v3：DuckDB 盯上的，是企业湖仓真正的主航道
如果说 Lance 指向的是 AI 数据未来，那么 Iceberg v3 指向的就是企业数据平台的现实。
这次 1.5.1 对 Iceberg 的增强，官方列得很清楚：
VARIANTTIMESTAMP_NS默认值 deletion vectors 分区表插入 分区表创建 Parquet Copy 选项支持
别小看这几项。它们背后的意义不是“支持列表又长了几条”，而是：
DuckDB 正在补齐作为开放表格式执行端所需要的关键语义。
尤其是 deletion vectors 这类能力，官方明确点出它使 DuckDB 能对 v3 表执行 delete 和 update。这个信号非常关键，因为它说明 DuckDB 不是只想读 Iceberg 元数据、扫底层 Parquet，它要更深入地理解 Iceberg 的事务语义和表演进能力。
DuckDB 的 Iceberg 扩展文档也明确说明，它可以配合 httpfs 或 azure 扩展访问对象存储上的 Iceberg 表，比如 S3 和 Azure Blob Storage。
这意味着对企业架构来说，DuckDB 的角色正在变化：
它不只是“本地分析器” 它也不只是“开发者桌面上的 SQL 工具” 它越来越像一个轻量但足够懂开放表格式的执行节点
Iceberg v3 的典型场景，是企业湖仓“最后一公里执行”
Iceberg 这类格式最适合的，不是个人玩具项目，而是需要：
跨引擎共享表格式 对象存储为底座 元数据治理 表模式演进 分区管理 删除、更新、快照访问
DuckDB 现在在这些方向上的补齐，最直接的受益者其实是三类人：
1）数据平台团队
你有统一的湖仓表，但并不是每个消费场景都值得起一个常驻大集群。DuckDB 这种嵌入式执行层，适合放在验证、抽样、离线分析、轻量服务、边缘节点等位置，直接消费 Iceberg 表。
2）应用开发团队
很多产品功能需要“读一点分析数据”，但又不值得为了这件事专门引入一整套远端查询基础设施。DuckDB 一旦能更完整地理解 Iceberg v3，应用就更容易直接接开放表格式，而不是额外造一层中转。
3）数据库管理员和架构师
这类支持意味着你可以重新思考系统分层：
不是所有数据消费都必须汇聚到一个中心化服务层。 一部分查询能力，完全可以贴着数据、贴着应用、贴着任务运行。前提是这个执行层足够懂表格式语义，而 DuckDB 正在补这块。
把 Lance 和 Iceberg 放在一起看，你就知道 DuckDB 想干什么了
单看 Lance，你会觉得 DuckDB 在追 AI。
单看 Iceberg v3，你会觉得 DuckDB 在追湖仓。
两者放在一起，意思就变了：DuckDB 想做一个横跨“AI 数据平面”和“企业湖仓平面”的统一执行层。
这就是它的野心。
因为今天的数据世界，正在同时发生两件事：
第一件事，企业数据越来越往开放表格式集中。
第二件事，AI 数据越来越需要既支持向量、又支持文本、又支持结构化元数据的统一访问方式。
绝大多数系统只盯住其中一边：
要么是传统数仓/湖仓侧，
要么是 AI 检索/向量数据库侧。
而 DuckDB 现在做的事，是试图让自己同时理解这两种世界。
这不是简单的“多支持两个格式”，而是在抢一个更值钱的位置：
谁能成为多种数据格式之上的默认计算入口，谁就有机会成为新的数据操作系统。
这是 DuckDB 这轮动作背后的真正逻辑。
但这个判断成立，有一个前提
这里必须讲清楚，否则就容易吹过头。
我的判断成立，前提是：
你的核心诉求是 分析型执行 你看重 嵌入式、轻量化、近数据执行 你希望 减少数据搬运和系统中转 你的场景需要同时碰到 开放湖仓格式 或 AI 数据格式
在这些条件下，DuckDB 继续补 Lance 和 Iceberg v3，意义巨大。
因为它直接降低了“应用、任务、分析脚本、边缘节点”接入现代数据格式的门槛。
但如果这些条件崩塌，比如你要的是：
高并发 OLTP 强中心化服务治理 多租户强隔离 重事务协调 海量在线小写入
那 DuckDB 的角色就不该被拔得过高。
它更适合做的是： 执行层、消费层、分析层、内嵌层，而不是一切场景的主数据库。
也正因为如此，DuckDB 的野心才更现实：
它不是在喊“我要替代所有数据库”，
它是在做一件更聪明的事——
把越来越多原本依赖重型平台的数据能力，压缩进一个足够轻、足够近、又足够聪明的执行引擎里。
最后一句
DuckDB 1.5.1 表面上是个小版本。
但只要你把 Lance format 和 Iceberg v3 放在同一个坐标系里看，你就会发现：
DuckDB 真正想拿下的，不是“本地查文件”这个小市场。
它想拿下的是 ——
未来应用、AI 系统、湖仓平台之间那层统一的数据执行入口。
你怎么看？
你觉得 DuckDB 最终会停留在“开发者神器”，还是会真的长成 AI + 湖仓时代的通用执行层？