What is the difference between Milvus 2.x's coordinator-based architecture and the direction of Milvus 3.0's lake-native design?

Milvus 2.x's architecture, the stable, widely-deployed foundation covered throughout most of this material, centers on the coordinator/worker split described earlier: data is ingested into Milvus's own managed storage (object storage plus Milvus-controlled segment and index formats), and applications bring data into that system before it can be queried.

Milvus 3.0, which reached general availability in mid-2026, extends that foundation with what its documentation describes as "lake-native" data access: the ability to query data directly from external data lake formats (like Apache Iceberg, Parquet, and Lance) sitting in existing object storage, without first extracting, transforming, and loading it into Milvus's own storage. This is paired with a new underlying storage engine and features aimed at reducing the data-movement overhead that previously existed between an organization's broader data lake and its vector search layer specifically.

For most day-to-day interview and operational purposes, the 2.x architecture (Proxy, Coordinators, Worker nodes, object storage) remains the correct mental model, since it's what the large majority of current production deployments run on and what the core similarity-search mechanics described throughout this material are built around; the 3.0 direction is best understood as an evolution extending that same foundation toward tighter data-lake integration, rather than a replacement of the underlying search and indexing concepts.