In brief

Milvus 3.0, released on July 29, 2026, moves the vector database closer to a retrieval layer over a data lake. External Collection can index and search data that remains in S3-compatible object storage or an Iceberg table, without requiring the entire source table to be copied into Milvus first.

For a business, this can remove data duplication and part of the ETL workload. The design is most attractive where a data lake already exists and has clear ownership. Building Iceberg, object storage and a distributed Milvus deployment solely for a first RAG pilot is usually more expensive than beginning with a simple managed collection.

What changed in version 3.0

The release centres on External Collection and Storage V3. Milvus can expose external files and tables as a collection, build search structures over them and keep the familiar retrieval API while source data remains in place.

The stable release includes:

  • External Collection support for Parquet, Lance, Iceberg, Vortex and `milvus-table`;
  • derived fields such as BM25 vectors, MinHash and embeddings over external data;
  • refresh after columns are added without a complete rebuild;
  • online field addition, backfill and removal;
  • SINDI, Block-Max WAND and Block-Max MaxScore sparse indexes;
  • long TEXT values backed by LOB files;
  • faceted search, server-side aggregation and reranking chains;
  • direct FAISS configuration through index-factory strings;
  • independent Woodpecker log deployment for larger clusters.

This is not a cosmetic SDK update. It changes the boundary between the system of record, the index and the retrieval service.

How lake-native RAG works

In a conventional RAG pipeline, documents land in object storage or a warehouse. An ETL process extracts text, creates embeddings and copies them into a vector database. Every source update must then be synchronised, and the team must monitor whether the index has fallen behind.

With an external collection:

1. Source tables and files stay in object storage.
2. Table metadata is versioned, for example with Iceberg.
3. Milvus maps external fields into its collection schema.
4. Retrieval features are built over those fields.
5. Applications use Milvus as the search layer.
6. Refresh makes a newer external-table version visible.

This reduces duplication and clarifies responsibility. The data platform owns the source and its lifecycle; the search team owns indexes, relevance and the retrieval SLO.

Where the business value appears

Fewer copies and ETL jobs

A document archive often exists as originals, cleaned text, chunks, embeddings, indexes and backups. Searching data in place can remove at least one managed copy and reduce synchronisation work.

Changing the embedding model without downtime

Milvus 3.0 supports adding a field, backfilling it and later removing the previous field while queries continue. Old and new embeddings can coexist while the team compares retrieval quality.

Hybrid retrieval in one layer

BM25, dense and sparse vectors, filters, facets and reranking can be combined in a search request. For a catalogue, knowledge base or support archive, this reduces client-side orchestration.

Constraints that should not be missed

Storage V3 is disabled by default and must be explicitly enabled. A 2.6-to-3.0 upgrade may initially permit rollback, but the guarantee ends after features that change serialised data formats are used. New index versions and published benchmarks should also be retested on the company's own workload.

External Collection does not repair the source data. Duplicates, obsolete documents and incorrect access rights remain defects; the new retrieval layer may simply deliver them faster.

Who should consider it

The architecture is reasonable when the company already has object storage and disciplined data versioning, a large or fast-growing corpus, several consumers of the same data, people who can operate Milvus and lakehouse components, a need to refresh embeddings without extended downtime, and measurable requirements for search and recovery.

For a smaller business with tens of thousands of documents, Qdrant, pgvector or a conventional Milvus collection may be simpler. A lakehouse is a tool for scale and duplication, not a certificate of architectural maturity.

A safe pilot

Choose one dataset where copying or delayed refresh has a visible cost; do not migrate the entire estate.

1. Record the source, size, change rate and owner.
2. Create an external collection in an isolated environment.
3. Test initial indexing and incremental refresh.
4. Measure how quickly a new document becomes searchable.
5. Compare Recall@k, nDCG and p95 latency with the current system.
6. Add a new embedding field and backfill it while reads continue.
7. Validate permissions at the source, collection and application layers.
8. Take a snapshot and restore the environment.
9. Prove rollback before using a new-format feature.
10. Calculate annual storage, compute, network and support cost.

Economics without architecture theatre

The business case is not just gigabytes. Count duplicate copies, daily ETL and reindexing, downtime during schema or embedding changes, network traffic, engineering time spent diagnosing drift, and the cost of operating a more specialised platform.

If the company already pays for a data lake, copies and heavy ETL, lake-native retrieval may simplify the environment. If those costs do not yet exist, Milvus 3.0 can create an infrastructure budget rather than reduce one.

Executive takeaway

Milvus 3.0 makes it possible for retrieval to live beside the source data rather than require another complete copy. That is valuable for large catalogues, archives and rapidly changing enterprise knowledge.

The next step is not “move to a lakehouse.” Select one expensive copying flow and prove three outcomes: fewer duplicates, faster index refresh and acceptable retrieval quality. The robot may stop carrying boxes, but someone still has to check the manifest.