What shipped
Zilliz released Milvus 3.0 on July 31, a major architectural upgrade to Milvus, which the company describes as the world's most widely adopted open-source vector database. The release stays under the Apache 2.0 license and keeps Milvus as a graduated project under LF AI and Data, the Linux Foundation's data and AI umbrella. The headline change is a lake-native architecture that lets Milvus build indexes and serve retrieval directly against data already sitting in object storage, rather than requiring teams to copy data into a dedicated vector store first. That distinction sounds narrow, but it removes an entire category of data pipeline that most retrieval-augmented generation teams have had to build and maintain by hand up to now.
James Luan, Zilliz's co-founder and CTO, framed the release around a specific pain point: AI data is getting larger, richer, and more dynamic, but the systems serving and improving that data have stayed fragmented across separate stores for raw data, embeddings, and search indexes. Milvus 3.0's pitch is bringing production retrieval closer to wherever the data already lives, through a feature called External Collections that supports open table and file formats including Lance, Iceberg, Parquet, and Vortex. That list of supported formats is itself notable, since it covers most of the open table formats enterprise data teams have already standardized on for their broader lakehouse buildouts.
The storage engine doing the real work
Underneath External Collections sits Loon, a new manifest-based storage engine built on the open, Arrow-compatible Vortex format. Loon is designed specifically to reduce read amplification, the extra I/O overhead that shows up when a system has to scan more data than it strictly needs to answer a query, which is a common problem when serving vector search directly against object storage instead of an index optimized purely for that access pattern. Reducing that overhead is what makes low-latency access to lake-stored data plausible at production scale rather than just in a demo environment.
This matters because the entire pitch behind lake-native vector search collapses if query latency degrades once data lives in cheaper object storage instead of a dedicated, memory-optimized index. Teams evaluating Milvus 3.0 for production retrieval should treat Loon's actual latency numbers under realistic query load, not the architectural description alone, as the detail that determines whether this upgrade is usable for latency-sensitive applications or better suited to less time-critical batch retrieval workloads instead.
Retrieval capability beyond nearest-neighbor search
Milvus 3.0 extends well past traditional nearest-neighbor vector search. New capabilities include server-side sorting, aggregation, and faceted search, alongside sparse and hybrid retrieval that combines keyword-style and vector-based matching in a single query. The release also adds native multi-vector retrieval through a feature called StructList, which supports late-interaction retrieval models such as ColBERT and ColPali, an increasingly common pattern for applications that need to compare multiple embeddings per document rather than a single vector representation.
Additional additions include an optimized sparse index, server-side generation of SINDI learned sparse vectors, server-side MinHash generation, support for nullable vector fields, and broader compatibility with Faiss-based indexes. Taken together, these are the kinds of capabilities that matter specifically for teams running retrieval-augmented generation and agentic search at production scale, where a single nearest-neighbor lookup is rarely sufficient and applications increasingly need several retrieval strategies combined inside one query path. Supporting late-interaction models natively, rather than through a bolted-on reranking step, is the detail most likely to matter for teams building search over long or highly structured documents.
Positioning Milvus inside existing data pipelines
Perhaps the most telling addition for enterprise data teams is a new Spark DataSource V2 connector supporting Spark, Databricks, and EMR workflows, alongside a new Snapshots feature for point-in-time datasets. Both signal that Zilliz wants Milvus treated as a component inside an existing enterprise data pipeline rather than a specialized system a separate AI team stands up and maintains on its own. Deployment support for Kubernetes and Docker, including air-gapped environments, further targets regulated enterprises that cannot run a pure SaaS vector database.
SDKs for Python, Go, and Node.js are available at launch, which covers the languages most retrieval and application engineering teams are already using rather than requiring a new toolchain. The combined effect of the pipeline integrations and deployment flexibility is a product clearly aimed at teams past the prototype stage of vector search, who need retrieval infrastructure that plugs into governance, orchestration, and deployment patterns already standardized elsewhere in the organization.
What this means for the CTO's roadmap
The vector database category has mostly competed on raw search quality and cost so far. Milvus 3.0's lake-native bet suggests the next phase of competition will be about how well a vector database integrates into an organization's existing data lake and governance model, rather than how it performs as a standalone system in isolation. That is a meaningful shift for any team currently running a dedicated vector database alongside, rather than inside, its core data platform.
Teams already invested in an open table format like Iceberg or Delta should evaluate whether Milvus 3.0's External Collections genuinely eliminates a data duplication step they are paying for today, both in storage cost and in the operational burden of keeping two copies of data in sync. For teams earlier in their retrieval buildout, the more durable signal is architectural: vector search is being pulled into the same lakehouse conversation as the rest of enterprise data, and infrastructure decisions made now should assume that convergence continues.
