Milvus 3.0: Lake-Native Vector Search Without the Copy

Milvus 3.0, released July 31, introduces a lake-native architecture that allows vector search directly over data in object storage without copying, reducing I/O per point read from 9.4 MB to 0.07 MB (a 135x reduction) and improving sparse vector query throughput up to 10x with the new SINDI algorithm. The update, from Zilliz, targets the vector copy tax in RAG pipelines by enabling External Collections over Parquet, Lance, Iceberg, or Vortex files in S3, GCS, or Azure Blob, with read-only, zero-copy access.

If you’re running a serious RAG pipeline, you’re probably paying a tax you’ve stopped questioning: the vector copy tax. Your embeddings already live in object storage — S3 Parquet, an Iceberg table, a Lance file. Then you copy them into your vector database. Then you build a sync job to keep them in sync. Then you watch your storage bill grow and your data governance team send increasingly pointed emails. Milvus 3.0, released July 31, makes a direct argument against that workflow. The biggest architectural overhaul since the project launched introduces a lake-native approach: Milvus can now build and serve production indexes directly over data that stays in object storage, with no copy required. It’s a meaningful shift, and it changes the calculus for any team running AI workloads on top of a data lake. What lake-native actually means The flagship feature is External Collections. Instead of ingesting data into Milvus, you define a Milvus collection that references files where they already live — Parquet, Lance, Iceberg, or Vortex — in S3, GCS, or Azure Blob. Milvus owns the schema, the indexes, and query execution. The data doesn’t move. This is particularly useful in governed environments. If your data residency rules or compliance requirements demand that source data stay put, External Collections is the cleanest path to vector search without touching data governance. The access is read-only and zero-copy — Milvus never takes custody of the records, only the indexes over them. The practical implication: for teams already maintaining a data lake with embeddings in open table formats, the case for adding a separate vector database silo just got significantly weaker. You get Milvus’s query engine without the ETL overhead, the sync pipeline, or the duplicated storage cost. According to a breakdown of enterprise AI pipeline costs https://bitronix.ai/blogs/enterprise-ai-agent-rag-cost-breakdown , the LLM API is often the smallest recurring line item in a production RAG system — vector DB hosting and synchronization engineering are the bigger ones. This problem is also relevant in context of the broader vector search expansion across cloud platforms https://byteiota.com/dynamodb-vector-search-goes-ga-what-aws-devs-must-know/ . The performance story Lake-native architectures have one obvious problem: object storage is slow. Reading point queries from S3 is orders of magnitude slower than reading from local NVMe. Milvus’s answer is the Loon storage engine — a new manifest-based system that uses Vortex, an Arrow-compatible columnar format, to aggressively reduce read amplification. The numbers are striking. Per Zilliz’s internal benchmarks on 3 million rows of 128-dimensional vectors, I/O per point read drops from approximately 9.4 MB Parquet baseline to 0.07 MB with Vortex and Loon — a 135x reduction in data movement. That’s what closes the gap between object storage and in-memory latency enough to make production retrieval viable. The sparse vector improvements are equally concrete. Milvus 3.0 introduces SINDI, a new algorithm optimized for learned sparse embeddings like SPLADE, achieving up to 10x the query throughput of MaxScore across four benchmark datasets — worst-case around 5x. Combined with block-compressed postings and quantization, the sparse index footprint shrinks by roughly 3x compared to Milvus 2.6 at comparable recall. You can see the full technical breakdown in the official announcement https://milvus.io/blog/announcing-milvus-3-lake-native-vector-search-and-a-more-powerful-retrieval-engine.md . For teams running hybrid search — dense vectors plus sparse BM25 — this matters directly. Faster sparse search means faster hybrid queries, and a 3x smaller index means lower hosting costs at the same scale. What changes in your stack Beyond the headline features, three practical improvements are worth knowing about. Online schema evolution. You can now add, fill, and drop columns on a live collection without rebuilding from scratch. If you need to add a new embedding model’s output as a column, or retire a field, that’s a live operation — no downtime, no rebuild. Milvus supports both external backfill values computed outside and loaded and inner backfill values like BM25 computed by Milvus itself . Spark integration via DataSource V2. Milvus collections are now readable by Spark, Databricks, and Amazon EMR as standard batch data sources. Paired with the new Snapshots feature — point-in-time, read-only collection views — you can run re-embedding or deduplication jobs on a stable snapshot while production writes continue on the live collection. Composable reranking. The new Function Chain API lets you define a typed reranking pipeline as part of a single search request — combining early rescoring, model-based reranking, sorting, and candidate trimming without writing client-side orchestration code. It executes as a single request, not a multi-step client loop. Who this is actually for Milvus 3.0 is not a universal upgrade argument. If your team is small and your vector dataset fits comfortably in a managed service, the lake-native architecture adds complexity you probably don’t need. Based on current vector DB comparisons https://dev.to/darshit 01/the-best-vector-database-in-2026-qdrant-vs-pinecone-vs-weaviate-vs-milvus-vs-pgvector-3147 , Qdrant remains the stronger default for most RAG pipelines on cost and filtering performance, and if you’re already running PostgreSQL, pgvector https://byteiota.com/pgvector-082-cve-2026-3172/ is still the right answer for simpler workloads. Where Milvus 3.0 makes a clear case is at enterprise scale: teams running petabyte-class data lakes, organizations with strict data governance requirements, and pipelines where the ETL cost of feeding a separate vector database is a real budget line. For those teams, the ability to point Milvus at existing S3 data and skip the copy step is a genuine operational improvement, not a feature-sheet bullet. Zilliz CTO James Luan put it plainly in Zilliz’s press release https://www.businesswire.com/news/home/20260731560192/en/Zilliz-Announces-Milvus-3.0-Making-the-Worlds-Most-Adopted-Open-Source-Vector-Database-Lake-Native : “AI data is becoming larger, richer, and more dynamic, yet systems remain fragmented. Milvus 3.0 brings production retrieval closer to where data already lives.” The vector database market has been fragmenting for years — every major cloud bolting on its own embedding layer, every vendor claiming to be the AI data layer. The lake-native direction is a different bet: instead of pulling data into a new silo, make the vector engine a citizen of the infrastructure you already have. Whether that bet pays off depends on whether open table formats become the default home for enterprise AI data. Given how fast Iceberg and Lance are moving, that’s not a stretch. The full release notes are available on the Milvus documentation site https://milvus.io/docs/release notes.md . Storage V3 Loon is opt-in and disabled by default — rollback from 3.0 to 2.6 is supported without enabling it.