Milvus 3.0 官宣开源：4 个真改工作流的能力，剩下 16 项要看场景再上

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 187 篇，Milvus 最佳实战「2026」系列第 26 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

Milvus 3.0 官宣开源信息图封面

Milvus 3.0.0 在 2026 年 7 月 29 日 GA（来自 GitHub tag 与 LF AI & Data 基金会的双源验证）。官方 release notes 里有一句话被很多人跳过：

Building on the lake-native architecture introduced in 3.0-beta, this release completes what the beta started.

这句话很重要。它不是谦虚，是把 3.0 定性成 beta 的句号，而不是新功能堆叠。如果你只把它当成 2.6 → 3.0 的常规升级看，会错过这条主线。

翻完一遍源码（internal/core/src/storage/loon_ffi/、internal/storagev2/、pkg/streaming/walimpls/）和官方文档库（web-content/v3.0.x），我对这次发布的判断是：底层是 Storage V3 / Loon 这层抽象替换，上层是 External Collection、Snapshots、Online Schema、TEXT 字段、Sparse Index 重构，它们才是真正改你工作流的东西。 聊新功能之前必须先聊清楚这层替换，不然容易把上线即用和代码已存在混为一谈。

下面这篇文章不打算逐条列 release notes 上的 20+ 项功能。只挑改变工作流的几个能力、它们的边界、以及上线前必须知道的几个门槛来写。

1. 主线：把云原生换成湖原生

Milvus 2.x 的核心卖点是云原生 + 存算分离：无状态组件、对象存储做底、500+ 节点可扩。这套思路的边界在 2.6 已经摸到了，再加数据就要复制一份到 Milvus。

3.0 不打算解决扩的问题，它换了抽象。从 release notes 提到的新一代存储抽象、源码里 internal/storagev2/ 目录、loon_ffi/ 路径下的 FFI 封装来看，Milvus 把存储底座换成了 Storage V3 / Loon：基于 object storage 的 manifest 列存格式。

更准确说，Loon 干的是这件事，把 segment 的元数据（manifest）和数据文件（column files）解耦，query 时按 manifest 精准取列。对用户表现出来的效果，官方博客给了一组厂商口径数字（3M 行 / 128-dim / S3 / 256 concurrent readers）：Parquet 基础读每点 ~9.4 MB，Vortex + Loon 压到 ~0.07 MB，约 135 倍 I/O 节省。

但要注意：这个数字只有官方博客一处来源，没找到第三方独立复现。在你自己的数据集上能不能复现，取决于行数、向量维度、并发读模式、manifest pruning 命中率。我用 Loon 的 135× 是参考值，不是承诺。

这套底层替换的好处，到了上层能力才真正显现。

Milvus 2.x 云原生 与 3.0 lake-native 架构演进对比

2. 这 4 个能力，真正改变工作流

3.0 的 release notes 列了 20+ 项能力，但大部分是能力补全或工具链改进。下面这 4 项是直接改变你怎么用 Milvus 的能力，按对你影响大到小排序。

2.1 Online schema 演进：加字段、backfill、删字段，3.0 把环合上了

如果你用过生产级 Milvus 集合，这件事你一定踩过：embedding 模型换一代，要么停机双写，要么搞个 ETL 周期重建一遍集合。Schema 在线变更在 3.0 才算正式闭环。

官方博客对 add_collection_field 和 drop_collection_field 的描述很关键：只改 manifest，不重写 data files。换句话说，存量向量文件一个字节都不动，新增列只是元数据层面的事。

3.0 的 backfill 区分了两种方向，且必须分清：

• Inner backfill（已 GA）：函数计算的字段。比如给一个 text 列加 BM25 函数，输出列对存量数据自动算出来，不用双写
• External backfill（仍在 roadmap，3.0 之后）：值在 Milvus 外计算。看官方博客原话，take a snapshot → run Spark against the consistent view → compute a new column → write back → Milvus 增量索引。这条路径在 3.0 还不能直接走

这点容易被文档里含糊的措辞误导。我这边以官方博客（milvus.io/blog）为准，外加本地 release notes：external backfill 3.0 还没上线。换 embedding 模型走 hot path 这个能力，对很多人来说是最关心的，它是 3.1 的事。

2.2 External Collection：从 zero-copy 读到完整 lakehouse 检索流程

External Collection 在 3.0-beta 引入，3.0.0 把它扩展成更完整的形态。简单说：你能在 Milvus 里直接检索一份已经存在 Iceberg / Parquet 里的数据，不用把数据复制进 Milvus。

3.0.0 的新增强化（来自 release notes）：

1. External fields 可以作为 function output 字段，BM25、MinHash、text embedding 都能基于外部表数据计算
2. Refresh 支持 additive schema evolution，外部表新增列只 patch 受影响的 segments，不会 rebuild 整个 collection
3. 新增 milvus-table external format，Milvus Snapshot metadata 和 Storage V3 manifests 可以作为外部源

第三方实战（ideas.paasup.io）的复现确认了 zero-copy 可行：1,000 行 128-dim 随机向量 → Iceberg → External Collection → HNSW → 搜索返回 id∈0,999。Iceberg snapshot time-travel 也确认能挂出来。

但有几个坑要记：

• External Collection 是 read-only。写入和 CDC 自动同步在 3.1 的 CDC-fresh external indexes
• Schema 变更靠 tbl.overwrite() 重写 Parquet + drop + recreate collection，Loon 没办法给老文件补 NULL 列
• external_source 必须指向 metadata.json 文件路径，不是目录
• S3 URL scheme 必须是 s3://，不能用 minio://

这点对 Lakehouse 用户价值最大。你已经有 Iceberg / Delta 数据湖，让 Milvus 在上面建索引检索，不用 ETL 流水线。

2.3 TEXT 字段 + Sparse Index 重构：RAG 和 BM25 同时变

3.0 把 TEXT 字段提升到一等公民。设计上的关键变化（来自 release notes）：

• 长度限制在存储侧被移除，之前 TEXT 字段有长度上限，现在没了
• 小于 64 KB 的值 inline 存储；≥ 64 KB 进 partition-level LOB files（Vortex 格式），列只存 (file_id, offset) 引用
• LOB files 跨 segments 共享，compaction 时移动引用不重写文本

为什么这件事重要：RAG 场景里，向量和源文本现在可以放在同一个 store 里一次 IO 取出，不用再额外维护一个 blob store / S3 桶 / 文档数据库。3.0 之前的常见做法是把原文放 S3，向量存 Milvus，召回后还要再走一次 S3。多一跳 IO，多一份对象存储成本。

Sparse Index 这条线 3.0 重写了。引入三个算法（release notes + arxiv 论文）：

• SINDI（arxiv.org/abs/2509.08395）：在 learned sparse embeddings 上
• Block-Max WAND 和 Block-Max MaxScore（block-max 是这类剪枝算法的通用命名，作者补注）

厂商口径基准（release notes + LF AI & Data 博客多源一致）：

• 启用新 index version 后，SINDI 是 sparse IP search 的默认算法
• MaxScore 是 BM25 的默认算法
• 压缩 BM25 index 大小约为 2.6 sparse index 的 1/3（同等 recall）
• SINDI QPS 约为 MaxScore 的 10×（worst case 约 5×）

这些数字经厂商多源交叉确认，但仍属厂商内部基准。要决策是否迁移，建议在自己数据集上跑一遍 reindex benchmark。

Multi-vector 这条线严格说属于 StructArray 能力，和 Sparse Index 同属检索层但独立成线，这里列出来是因为 trade-off 思路相近。3.0 给了三种 trade-off（来自官方博客的 trade-off 表）：

官方说 Lemur 在多数数据集上 recall 与 TokenANN 持平或更优，但多数的具体数据集没列。这个判断也建议独立验证。

2.4 Woodpecker 当默认 WAL：运维侧变化

3.0 默认 WAL 已经是 Woodpecker（替代 2.x 默认的 Pulsar / Kafka），这不只是换组件：

• 支持 3 种 storage.type：minio（默认）/ local / service
• 支持 standalone service 部署（distributed / cluster 模式），独立扩缩、故障隔离、可观测

这块对运维的影响是直接的：少一个 ZooKeeper / BookKeeper 组件栈，少一份 Pulsar 集群的运维负担。看起来是好事，但有两个已知坑必须先说（详见下一节）。

Sparse Index 与 Multi-vector 检索策略算法对比

3. 落地前必须知道的 3 个门槛 + 2 个已知 bug

读完 release notes 觉得什么都好使，这是踩坑的常见起点。3.0 的几个 opt-in 开关和社区已知问题，是上线前必须核对的。

3.1 Storage V3 默认 disabled，但一旦开启就不可回滚

common.storage.useLoonFFI 默认是关闭的，这意味着依赖 Storage V3 的功能（Snapshot、TEXT 字段、External Collection 的 manifest 视图）默认不开，要手动开关。后续版本会默认开启。

更关键的一句：2.6 → 3.0 是兼容的，但一旦启用改变序列化数据格式的功能（如 Storage V3），回滚 2.6 不再可能。我的判断：把它当成 2.x 时代的小版本升级是危险的。生产灰度时，先在 staging 环境开 Storage V3，跑完数据格式迁移，再考虑 prod 切流量。

3.2 新 index 需要手动调高 version

新 sparse algorithms（SINDI 等）需要先把 dataCoord.targetVecIndexVersion=10 和 dataCoord.targetScalarIndexVersion=4 手动调起来，这是 opt-in。release notes 明示后续版本会默认开启。

3.3 Woodpecker 的两个已知问题

独立服务的 Woodpecker 默认对接到 local filesystem（minio / local 模式）。社区已有两个未在 3.0 release notes 明确修复的 issue，对 standalone 部署影响最大：

1. Issue #46067：切换 Woodpecker MQ + local storage 后，vector insertion rate 从 421 vec/sec 暴跌到 30 vec/sec（约 14× 慢）。
2. Discussion #45494（关联 Issue #45368）：docker compose down/up 后启动报 segment storage not writable，原因是 MinIO 中 files/wp/ 残留 stale write.lock 文件。用户原文（英文）：I had to reinstall Milvus and MINIO three times now。维护者 tinswzy 承诺在 v2.6.6 修复，3.0 是否同步修复未明示。

issue 里提的两个问题都会影响 3.0 默认配置的 standalone 部署。在生产环境大规模上线前，强烈建议先在测试集群复现这两个场景，或至少确认自己用的是 distributed / cluster 模式（独立 Woodpecker service），绕开 local storage 的坑。

Milvus 3.0 落地路径与 3 个门槛 2 个已知 bug 风险提示

4. 3.0 没解决的、3.1 在路上的事

3.1 路线图（来自官方 roadmap.md）已经明确回应了几个 3.0 的边界：

• CDC-fresh external indexes：直接解决 External Collection 不能写 的问题，让外部表增量同步到 Milvus
• Apache Paimon 和 Delta Lake support：External Collection 当前默认面向 Iceberg，主流湖格式的覆盖要等 3.1
• UDFs（User-Defined Functions）：在引擎内执行用户自定义逻辑
• Time-travel / schema evolution / snapshot rollback 完整化
• Predicate pushdown（page-index + bloom-filter pruning）、write-time primary-key dedup，性能侧继续打磨

如果你的核心场景是 lake 数据要写要更新，那 3.0 是过渡版本，3.1 才是目标版本。

商业生态上，3.0 之外还有个值得关注的视角。TechTarget 引用 Moor Insights & Strategy 分析师 Mike Leone 关于 lake-native 的安全责任担忧，原话：if Milvus is reading straight from a customer's tables, someone in security is going to ask who can see what。能力边界换了，安全治理的边界也跟着换了，这不是 Zilliz 一个人的问题，是整个 lakehouse 阵营的开放性代价。

Pinecone / Weaviate / Qdrant 也都在朝低搜索延迟 + lake 互操作的方向走。Snowflake / Databricks 已经在云数仓端有向量能力。和他们合作容易，他们接受标准列存；和别的 DB 供应商合作因为 storage engine 差异，原话是 might be difficult（来自 blocksandfiles）。这是 Milvus 商业侧的隐形墙，技术能力是一回事，生态兼容是另一回事。

总结

把这次发布拆穿看：

• 主线是架构替换（云原生 → lake-native），底层是 Storage V3 / Loon 的 manifest 列存抽象
• 真正改变工作流的能力：online schema 演进、External Collection、TEXT 字段、Sparse Index 重构、Woodpecker 默认 WAL，围绕这条主线展开
• 上线前必须知道的边界：Storage V3 开启后不可回滚 2.6；新 index 默认不开启；Woodpecker standalone + local storage 有两个未确认修复的社区 bug
• 外部 backfill、External Collection 写能力、Delta / Paimon 支持，3.1 才给

我赌的判断是：Milvus 3.0 这次 GA 的关键不是功能数量，而是把 beta 挖的坑填上、把上层能力的边界稳住。lake-native 是故事，compete what the beta started 才是这一版本号做的工作。

至于这个判断半年后还站不站得住，看一个信号就行：Snowflake / Databricks 会不会把 vector 当 first-class。如果他们做了，Milvus 这一轮 lake-native 布局的 ROI 会被压一个量级；如果没做，Milvus 3.0+ 的窗口就还在。在那之前，你在自己数据集上跑一遍 reindex 基准、复现 Woodpecker 两个 issue、再决定要不要把 embed 模型热路径赌在 3.1，比什么都实在。

说明：本文内容基于 Milvus 3.0.0 官方 release notes（来自 web-content/v3.0.x 文档库）、本地源码（milvus-io/milvus）和 GitHub tag、LF AI & Data 博客等公开来源交叉整理而成，文中标注的"厂商口径"数据（Loon 135× I/O、SINDI 10× QPS、BM25 1/3 大小等）均为官方公布的内部基准，未做独立复现。文中的能力边界、配置开关和兼容性结论仅供参考，实际部署效果请以你的业务数据和环境测试结果为准。如果有实际使用经验，欢迎在评论区分享交流。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！