Milvus 3.0 adds lake-native vector search

Milvus 3.0 brings lake-native vector search and new retrieval tools to Zilliz’s open source database.

Milvus 3.0 went generally available on July 16, 2026, and the update is built around one blunt idea: stop copying data around just to make AI search work. Zilliz says the new release reads directly from data lakes, adds a new retrieval engine, and cuts the overhead that has slowed a lot of production AI projects.

Why Zilliz changed the storage model

Zilliz co-founder and CTO James Luan said the update came from production users, including large language model labs and self-driving companies. Their complaint was familiar: teams were spending time and money moving data from lakes into a vector database before they could even start building useful retrieval systems.

That extra copy creates cost, but it also creates risk. If data is duplicated across systems, there is more to secure, more to audit, and more to break when pipelines change. Milvus 3.0 tries to keep one copy of the data in place and query it where it already lives.

Zilliz is not alone in chasing vector search demand. Pinecone, Qdrant, and Redis all compete in the same category, while cloud giants such as AWS, Google Cloud, and Oracle keep adding vector features to broader data platforms.

• Milvus now reads from object storage instead of forcing a full ingest step.
• Apache Iceberg tables can stay queryable in place.
• Zilliz says the new design reduces migration work and lowers operating cost.
• The release targets agentic AI and retrieval-heavy applications, not just classic similarity search.

What changed inside Milvus 3.0

The headline feature is lake-native access, but the release adds several pieces that matter in day-to-day use. The new storage engine, called Loon, is tuned for object storage reads so search latency drops and retrieval quality improves. That matters because object storage is cheap and durable, but it is slower than local or attached storage when you ask it to serve live queries.

StructList is aimed at multi-vector retrieval, which matters when one item has more than one representation. Think documents with text, images, and metadata, or product records that need both semantic and structured matching. Milvus 3.0 also adds an index for sparse and hybrid retrieval that uses less compute, which should matter for teams trying to keep inference bills under control.

Two other features are more practical than flashy. External Collections lets users define collections over data stored in Apache Iceberg, Apache Parquet, Lance, or Vortex. Snapshots gives read-only point-in-time views, which is useful when production data keeps changing but evaluation jobs need stable inputs.

“The area to pay attention to is indexing formats you never had to convert first,” said Mike Leone, an analyst at Moor Insights & Strategy.

That quote gets to the core of the release. A lot of vector search systems are easy to demo and annoying to run at scale. If Milvus can index data without making teams copy and reshape everything first, it removes one of the biggest reasons to avoid a specialist vector database in the first place.

How Milvus compares with the rest of the market

Kevin Petrie, an analyst at BARC U.S., said the release fits a broader move toward systems that combine analytical and transactional data for AI. He pointed to Databricks and Snowflake as examples of vendors pushing unified data access for AI workloads.

That matters because many enterprises want fewer moving parts. If a vendor already handles storage, processing, and vector search in one place, the pitch is easier to sell to platform teams. Zilliz is trying to answer that pressure without giving up the specialization that makes Milvus attractive to AI teams that care deeply about retrieval quality.

• Vector specialists like Milvus still tend to offer deeper search controls.
• Cloud platforms win on consolidation and fewer systems to operate.
• Lake-native indexing gives Zilliz a cleaner story than pure “load then search” tools.
• Snapshots help with evaluation, one of the messiest parts of production AI.

Leone also called Snapshots one of the most valuable additions because it lets teams evaluate retrieval behavior even while the underlying data keeps changing. That is a real operational pain point. If your data shifts every hour, you cannot reliably test whether a retrieval tweak improved results or just sampled a different dataset.

There is still a catch, though. Petrie noted that larger vendors can retrieve vector, graph, and tabular data from the same system, which simplifies architecture. Zilliz has to prove that a specialized database can stay simpler to adopt while still offering better retrieval for teams that need it.

What Zilliz says comes next

Zilliz says the second half of 2026 will bring deeper integrations between Milvus and data lakes, with a focus on auditing and debugging AI behavior. That is a smart direction. Once teams trust retrieval enough to put it into production, the next question becomes whether they can explain why a model returned a given answer.

The company also plans smarter storage and better elasticity at scale, and it wants the same Milvus 3.0 features to land in Zilliz Cloud. That part matters just as much as the open source release, because many teams would rather consume vector search as a managed service than run it themselves.

If Zilliz pulls off the roadmap, the real winner will be teams that want to query lake data in place instead of building another data copy just for embeddings. The open question is whether that convenience is enough to pull buyers away from broader platforms that already bundle vector search with the rest of the stack.

For now, Milvus 3.0 gives Zilliz a stronger pitch: less data movement, better retrieval controls, and a cleaner path from object storage to production AI. The next test is simple to state and hard to fake: can it make vector search good enough that teams stop treating it like a separate project?