Milvus 和 LanceDB 对比：格式、嵌入式库，还是分布式数据库？

能。Milvus 外部集合（Milvus 3.0+）把 external_source 指向 Lance 数据集目录、format 设为 lance-table，用 external_field 把每个字段映射到源列，然后原地建索引、原地提供检索。不导入、不复制：数据留在 Lance 里只读，Milvus 只保存 schema 映射、manifest、索引和缓存。

你的 Lance 数据集仍是唯一真源，Milvus 只是加了一层服务。Spark、Ray 或 pylance 照常写 fragment，同一批文件 LanceDB、DuckDB 和训练作业照常读。

• 开启 Storage V3（common.storage.useLoonFFI: true），用 external_source 和 external_spec 建 schema，然后 refresh、建索引、load、检索。
• Milvus 在自己的存储里建 HNSW、IVF 或 DiskANN 索引，从不写入数据集，Lance 自带的索引和版本原封不动。
• refresh 是显式、异步、增量的：新 fragment 被接入，未变化的数据保留原有 segment 和索引，完成前查询继续服务旧状态。
• 外部字段可以喂给 Function：BM25 稀疏向量或文本 embedding 在 Milvus 里生成，不往表里写回新列。
• 同一机制还能读 Apache Iceberg 表（format iceberg-table 加 snapshot_id）、Parquet 和 Vortex，详见数据湖向量检索。

LanceDB 的长处在数据层：表就是 Lance，同一批文件可以直接走 Arrow、pandas、Polars、DuckDB 和 PyTorch，每次写入都是可回溯的版本，图片、音频以 blob 形式和 embedding 放在一起，这也是它定位多模态数据湖的底气。Milvus 的长处在服务层：服务端混合检索自带 BM25，用 RRF、加权、衰减或模型 ranker 融合，并可用 Function Chain 编排；partition key 多租户支持百万级租户；RBAC；覆盖 GPU、DiskANN、RaBitQ 的索引目录；按所选一致性级别可见的流式摄入；以及同时覆盖 Lance 和 Iceberg 的外部集合。

从 AI 原生公司到大型企业，都在生产环境运行 Milvus 或 Zilliz Cloud（托管 Milvus）。milvus.io 用户墙上有 Salesforce、Walmart、NVIDIA、eBay、IBM、Cisco、Roblox、Reddit，也有 Exa.ai、OpenEvidence、Read.ai、Notta.ai、Plaud、Filevine。公开案例中的结果：

• OpenEvidence：基于 Zilliz Cloud，检索延迟低于 10 ms，峰值 4,000 QPS。
• Plaud：每个区域 100 亿+ 向量块，平均召回延迟低于 200 ms。
• Exa：借助混合检索，神经搜索延迟从秒级降到 200 ms 以内。
• Airtable：在 Kubernetes 上用 Milvus Operator 自建 Milvus，支撑语义检索。