Milvus 3.0-beta Deep Dive: Ten Core Features and the Complete Architecture Overhaul

On May 9, 2026, Milvus 3.0-beta was officially released — not as a simple version iteration, but as a fundamental overhaul of the entire system architecture. From the pain of data migration to the frustration of missing vectors, from redundant sorting and aggregation code to the complexity of multi-tenant management, version 3.0 tackles virtually every long-standing pain point accumulated by existing users. This article provides an in-depth look at the ten core features of this major upgrade and the technical logic behind them.

External Collection: The End of the Data Migration Era

In the Milvus 2.x era, if your data was stored on S3 or HDFS (in Parquet or Iceberg format) and you wanted to perform vector search, you had to first make a complete copy of the data into Milvus. This meant maintaining two copies of storage, writing ETL sync scripts, and tolerating inconsistencies where the data lake had already been updated but Milvus still held stale data.

The External Collection introduced in 3.0 completely changes this picture. You simply tell Milvus the folder path where your data resides, and it builds indexes and executes queries directly at the original location without ever touching the raw data. To use an analogy: it's like hiring a librarian who goes directly to your book warehouse to find books, rather than moving all the books to their office.

This feature is especially important for industries like finance and healthcare that have extremely strict data security and compliance requirements — regulations in these industries often prohibit data from leaving the company's data lake environment. At the same time, for teams looking to reduce storage costs and operational overhead, External Collection is an extremely attractive capability.

Snapshot: Perfect Isolation Between Offline and Online Workloads

In production environments, it's common to serve online search requests while simultaneously running offline tasks (such as A/B testing or data analysis). But conflicts between the two have always been a persistent headache: offline tasks might read dirty data from incomplete writes, or lock data being written to and cause online services to stall.

The Snapshot feature in 3.0 takes an extremely lightweight approach — it only records metadata without actually copying data, so creating a snapshot completes almost instantly and consumes virtually no additional storage. Offline tasks read from the snapshot while online operations continue writing to the original Collection, with zero interference between the two.

Even more elegantly, Spark can read data from Milvus directly through Snapshots, so data engineers no longer need to manually export data before analyzing it — the entire data analysis workflow becomes seamless.

Order By and Aggregation Queries: Database-Level Business Logic

Sorting by Business Rules

Previously, vector search could only sort by similarity, but real-world business scenarios often require secondary sorting within similar results by dimensions like price or publication date. The old approach was to pull all results to the client and write custom sorting code — inefficient and complex.

Milvus 3.0's Order By supports specifying multi-level sorting rules directly in the search statement — first by vector similarity, then by price ascending, then by publication date descending — all processed in a single pass by the database kernel, returning pre-sorted results directly.

Pushing Aggregation Queries Down to the Database Layer

Similarly, if you previously wanted to group by tenant and count records or compute the average of a field, you had to fetch all records and compute at the application layer, resulting in massive network transfer and redundant code. Now Milvus 3.0 supports writing aggregation logic directly in queries — group by tenant, count records, compute average scores, find maximum timestamps — all computed inside the database, returning only the final results, with code conciseness comparable to SQL.

No Vector and Online Column Addition: Flexible Schema Evolution

Vector Fields Can Be Temporarily Empty

In scenarios involving asynchronous embedding generation, you previously had to either wait for vectors to be generated before writing (adding latency) or write placeholder zero vectors first (polluting search results). Milvus 3.0 supports nullable vector fields — store records without vectors first, searches automatically skip these records, and vectors can be updated and filled in once they're computed.

Dynamically Adding Vector Columns

Online column addition allows you to add new vector fields to an existing Collection directly, without rebuilding the entire table. When business models change, you can immediately and flexibly extend the schema, dramatically reducing the cost of schema changes.

Entity-Level TTL: Fine-Grained Data Lifecycle Management

Previously, expiration policies could only be set uniformly at the Collection or Partition level. If a single table contained thousands of tenants — Tenant A retaining data for 30 days, Tenant B for 90 days — you had to write complex scheduled table-scanning scripts for manual cleanup.

Milvus 3.0's entity-level TTL allows you to designate a timestamp field in the schema as the TTL field. Each record carries its own expiration time when written, and the system automatically cleans up expired data in the background. This is particularly useful for implementing GDPR's "right to be forgotten," cleaning up session data, managing conversation histories, and similar scenarios.

Ambulist: Multiple Vectors in a Single Record

When processing long documents, it's common practice to split them into multiple chunks and generate multiple vectors. Previously, you either had to split them into multiple records (losing inter-chunk associations) or manually pack them into complex structures (risking memory overflow).

Milvus 3.0's Ambulist allows a single record to store a list of vectors directly. Combined with DiskANN disk-based indexing, even massive datasets won't cause out-of-memory issues. This is also the first step toward Milvus's multi-vector support.

File Resource and Storage V3: Infrastructure-Level Upgrades

Unified Text Search Configuration Management

In healthcare, legal, Chinese-language, and other specialized scenarios, custom dictionaries and synonyms are critical for tokenization quality. Milvus 3.0's File Resource allows you to upload custom dictionaries, synonym lists, and stopword files to Milvus's file resource manager. Once registered, they can be shared across tokenizers, filters, BM25 algorithms, full-text matching, and other features — multiple Collections sharing a single set of configurations, ending the era of copy-pasting config files everywhere.

The All-New Storage V3 Engine

Storage V3 is a segment-based columnar storage engine introduced in Milvus 3.0, where all data and metadata are stored directly on object storage (such as S3). Each modification generates a new immutable manifest snapshot, and delete operations only record markers in the delta log without rewriting files, ensuring structural stability of the file system.

Most critically, data files are self-describing — any reader (such as Spark) can parse file contents directly given just the storage path, without depending on Milvus's central metadata service. Combined with periodic Compaction (small file merging), file fragmentation is avoided. Storage V3 lays a solid foundation for the lakehouse architecture, and both External Collection and Snapshot are built on top of it.

GA Release Outlook: More Features to Look Forward To

As a beta release, Milvus 3.0 still has some important features that aren't yet ready. Upgrades to look forward to in the GA release include:

• Multi-vector enhancements: Struct List filtering, multi-vector and Late Interaction acceleration capabilities
• Data management: Global PK deduplication, field deletion, backfill, plus new Text and Blob types supporting direct storage and search of raw files like text, images, and videos
• Search experience: More Like This (finding similar content directly from example documents), semantic enhancement, result highlighting, and more
• Enterprise features: Snapshot-based backup and recovery, end-to-end audit logging, more granular multi-tenant management, and high-availability clusters
• Vector lake upgrades: Upgrade to version 0.2 with deep Spark integration, supporting offline indexing, clustering, and deduplication

Conclusion

The release of Milvus 3.0-beta marks its official transition from a pure vector search engine to an AI data infrastructure platform. By eliminating data migration through External Collection, achieving read-write isolation through Snapshots, pushing business logic down to the database layer through Order By and aggregation queries, and enabling lakehouse integration through Storage V3 — these improvements are not a scattered collection of features, but a systematic overhaul driven by a clear architectural vision. For teams building AI applications, this upgrade deserves serious attention and evaluation.