Milvus Roadmap 2025

[yiwen92]

Milvus 2025 Roadmap Discussion

Objective: Facilitate community collaboration to prioritize features and collect scenario-specific feedback.
How to Participate: Comment on specific features with your use cases or implementation suggestions, please feel free to use reactions (👍 for high priority) to indicate the importance of each feature.

---

Category 1: AI-Driven Unstructured Data Processing

• Data-In/Out: Native integration with major model services for raw text ingestion
• Original Data Handling: Text/URL reference support for raw data processing
• Tensor Support: Vector list implementation (for ColBERT/CoPali/Video scenarios)
• Extended Data Types: DateTime, Map, GIS support based on requirements
• Iterative Search: Query vector refinement through user‘s feedback

---

Category 2: Search Quality & Performance

• Advanced Matching: phrase_match & multi_match capabilities
• Analyzer Upgrade: Enhance Analyzer with expanded tokenizer support and improved observability
• JSON Optimization: Faster filtering through improved indexing
• Execution Sorting: Scalar field-based result ordering
• Advanced Reranker: Model-based reranking & custom scoring functions
• Iterative Search: Query vector refinement through user‘s feedback

---

Category 3: Rich Functionality & Management

• Schema Change: Add/delete field, modify varchar length
• Scalar Aggregations: count/distinct/min/max operations
• Support UDF: Support user defined function
• Data Versioning: Snapshot-based rollback system
• Data Clustering: Co-location through configuration
• Data Sampling: Fast get results based on sampling data

---

Category 4: Architecture Upgrade & Easy Deployment

• Stream Node: Simplified incremental data ingestion
• MixCoord: Unified coordinator architecture
• Logstore Independence: Reduced external dependencies like pulsar
• PK Deduplication: Global primary key deduplication

---

Category 5: Vector Lake Solution & Cost Efficiency

• Tiered Storage: Hot/cold data separation for lower storage cost
• Data Evict Policy: Users can define their own data evict policy
• Bulk Updates: Support field-specific value modifications, ETL etc
• Large TopK: Return massive datasets
• VTS GA: Connect to different sources of data
• Advanced Quantization: Optimize memory consumption and performance based on quantization techniques
• Resource Elasticity: Dynamically scale resources to accommodate varying write loads, read loads, and background task loads

---

Note: We will carefully listen to your feedback and appropriately adjust and iterate our roadmap, especially the features planned for Milvus 3.0.

[Niceies]

User experience

1. There are many basic parameters for deployment. It took me an afternoon to deploy the milvus cluster for the first time (with basic helm and basic deployment of other components). I only configured basic parameters (including milvus and other dependent components): cpu, memory, disk, auth, addressport, etc., up to 120. The more parameters, the easier it is to make mistakes. Of course, you can also use a layer of deployment plug-in to maintain the deployment scenario and fine-tune, but if the deployment of milvus itself is relatively simple, you don't need this auxiliary tool.
2. The compilation environment is quite strict. I tried to install the build guide to build the deployment environment, but various errors (related to version dependency) kept appearing during the compilation process. It should be a problem with the dependency on the C library. In the end, I could only compile successfully through the compilation image provided by the official. In addition, the dependent library has high requirements for external network connectivity, which should be caused by the reference of more C libraries. When I compiled on the intranet (limited by the office environment), I needed to open proxy sources such as go and github, and modify the download address in the code. Some C addresses were hard-coded and could not be modified. I could only replace the proxy source by modifying the python download code. I built the rust library on the intranet to succeed.
3. The community releases versions frequently and is in a stage of rapid iteration. From the announcements, many of them are about improving stability and reliability, and need to be upgraded as soon as possible. However, for some users, frequent upgrades are not possible. We hope to ensure stability and reliability as much as possible when developing new functions and iterations.
4. Are the related versions of milvus-backup, birdwatch, milvus-helm, and milvus-operator related? Sometimes, when using the backup function, deployment, or debugging with the wrong version, the function will fail and you need to try to adjust it back and forth.

Subsequent use plan

1. Continuously update the community version
2. Test the use of mmap to reduce performance while meeting performance requirements
3. Compare es's full-text search capabilities and scenarios to decide whether to replace es

Summary
I hope to use a database that is simpler, more user-friendly, more reliable, and better than similar databases in terms of core capabilities such as vector search and full-text search.

[yiwen92]

Thank you for your feedback.

1. First, we recommend using [this sizing tool]to estimate capacity and obtain a default configuration file, so you don’t need to configure everything manually. Additionally, we do have plans to simplify Milvus deployment management and dependencies, which is also reflected in our roadmap. Lastly, we plan to release best practices and more granular guidance on deployment and parameter configuration in the near future, either as a blog post or documentation.

2. We will work on optimizing it.

3. Before each release, we conduct thorough testing to ensure overall stability and compatibility. However, unforeseen bugs may still arise, which we will address through future releases. We recommend that community users follow our latest versions at an appropriate frequency to benefit from new features and optimizations.

4. Please refer to our release notes, where we provide details on compatibility.

[xiaofan-luan]

User experience

1. There are many basic parameters for deployment. It took me an afternoon to deploy the milvus cluster for the first time (with basic helm and basic deployment of other components). I only configured basic parameters (including milvus and other dependent components): cpu, memory, disk, auth, addressport, etc., up to 120. The more parameters, the easier it is to make mistakes. Of course, you can also use a layer of deployment plug-in to maintain the deployment scenario and fine-tune, but if the deployment of milvus itself is relatively simple, you don't need this auxiliary tool.
2. The compilation environment is quite strict. I tried to install the build guide to build the deployment environment, but various errors (related to version dependency) kept appearing during the compilation process. It should be a problem with the dependency on the C library. In the end, I could only compile successfully through the compilation image provided by the official. In addition, the dependent library has high requirements for external network connectivity, which should be caused by the reference of more C libraries. When I compiled on the intranet (limited by the office environment), I needed to open proxy sources such as go and github, and modify the download address in the code. Some C addresses were hard-coded and could not be modified. I could only replace the proxy source by modifying the python download code. I built the rust library on the intranet to succeed.
3. The community releases versions frequently and is in a stage of rapid iteration. From the announcements, many of them are about improving stability and reliability, and need to be upgraded as soon as possible. However, for some users, frequent upgrades are not possible. We hope to ensure stability and reliability as much as possible when developing new functions and iterations.
4. Are the related versions of milvus-backup, birdwatch, milvus-helm, and milvus-operator related? Sometimes, when using the backup function, deployment, or debugging with the wrong version, the function will fail and you need to try to adjust it back and forth.

Subsequent use plan

1. Continuously update the community version
2. Test the use of mmap to reduce performance while meeting performance requirements
3. Compare es's full-text search capabilities and scenarios to decide whether to replace es

Summary I hope to use a database that is simpler, more user-friendly, more reliable, and better than similar databases in terms of core capabilities such as vector search and full-text search.

Hi Niceies,

1. Milvus is a cloud native and cloud only system. The recommended way to run it is always using Zilliz cloud or host it in K8s with our image. If you can use K8s Operator or Helm your life will be much easier.

2. We'd like to take issues and contributions(Better) if possible. We have some experts in the community and they'd like to improve.

3. 2.4 branch is pretty stable and should be able to serve for quite well. 2.5/2.6 branch is actively under heavy development. If you are not a full text search, right not 2.4.23 works perfectly.

4. Good suggetion. I will definitely take this one.

If you have time I'd definitely like to meet, offer some help and receive more feedback to help you to achieve your target.

Feel free to reach me at james.luan@zilliz.com. I'd like to take an appointment from anyone else who has feedback for the community

[HuaJieHappy]

Schema Change: Add/delete field, modify varchar length
Bulk Updates: Support field-specific value modifications, ETL etc
在B端场景的RAG中，会遇到需要迁移数据/批量修改某个字段的值/新增、修改、删除某个字端，现阶段只能通过脚本把数据导出到新collection中，很需要这些功能的支持

[xiaofan-luan]

Schema Change: Add/delete field, modify varchar length Bulk Updates: Support field-specific value modifications, ETL etc 在B端场景的RAG中，会遇到需要迁移数据/批量修改某个字段的值/新增、修改、删除某个字端，现阶段只能通过脚本把数据导出到新collection中，很需要这些功能的支持

Add column/Delete column is already on the way.

We may opensource our special source modify schema using spark connector soon

[cherrylzhao]

another question is about Memory Optimization, I remember that milvus has a dynamic loading collection plan (according to vector filed) in https://milvus.io/docs/install-overview.md before, but now there is only Reduce OOM and load enhancement task, shall we continue to follow this task or not , thanks

[xiaofan-luan]

another question is about Memory Optimization, I remember that milvus has a dynamic loading collection plan (according to vector filed) in https://milvus.io/docs/install-overview.md before, but now there is only Reduce OOM and load enhancement task, shall we continue to follow this task or not , thanks

Lazy load will be part of Milvus 2.6.
We do have a special mode of Lazy load, which we don't require all data to be loaded into memory, but only cache hot datas.
But this could cause high search latency -> 1-2s if you hit cold data.
Another way to improve memory usage is to leverage MMap features and utilize local disk as a caching.

[cherrylzhao]

hi, @yiwen92
I'm interested in Logstore Independence, is there any docs I can follow ~,
message mechanism is core infrastructure for milvus, shall we give up the pub/sub mechanism or use another light-weight component to replace the pulsar?

[xiaofan-luan]

hi, @yiwen92 I'm interested in Logstore Independence, is there any docs I can follow ~, message mechanism is core infrastructure for milvus, shall we give up the pub/sub mechanism or use another light-weight component to replace the pulsar?

That's why build wood pecker, It's an implemeantion of log and used as a replacement of pulsar. see details at https://github.com/zilliztech/woodpecker

[YolandaLyj]

Are there any ideas for JSON Optimization at present?

[yhmo]

The work for JSON Optimization is always ongoing.
The release note of v2.5 introduced some improvements to JSON:

• v2.5.11
  Added support for binary range expressions in JSON path indexes (#41317).
  Added support for infix and suffix match types in JSON stats (#41388).

• v2.5.9
  Improve the performance of JSON key stats building by adding documents in batches (#40898)
  Align brute-force search results with JSON index behavior for the exists expression (#41056)

• v2.5.8
  Support JSON null/exists expressions (#41002)

• v2.5.7
  JSON Path Index: To address user needs for dynamic schemas, Milvus 2.5.7 introduces the ability to build indexes on dynamic columns and JSON columns. With this feature, you can create inverted indexes for specific dynamic columns or JSON paths, effectively bypassing the slower JSON load process and greatly enhancing query performance. For more information, refer to JSON Field.

[xiaofan-luan]

Are there any ideas for JSON Optimization at present?

JSON storage will be fully rewritten in some version of 2.6.x with a shredding mode.
We split json into multiple columns to accelerate filtering

[YolandaLyj]

Are there any ideas for JSON Optimization at present?

JSON storage will be fully rewritten in some version of 2.6.x with a shredding mode. We split json into multiple columns to accelerate filtering

After splitting into multiple columns, the advantage is that multiple columns can be queried concurrently?

[liaozhiyou]

milvus query search is not a replacement for elasticsearch

Version: MILVS 2.5.10, java sdk 2.5.9

Scenario: Try to replace es full-text search with milvus full-text search, and the hybrid search with milvus achieves the scenario requirements

Conclusion: It is currently not possible to complete the replacement in the scenario

We encountered the following problems:

1. Direct access to the total number of entities in the library is not supported

When trying to get the total number of entities in the library through the query function, we need to use the query iterator, because the query cannot be done without adding a filter condition. The average time to get about 8000 records using iterator batchSize 1000 is 1.2s, which is insufficient performance

search is a bit faster by 400ms-800ms (the interface performance is still not up to the goal) but you can't fetch the full library directly like Query because search can't make a request without parameters

2. Query does not support grouping, search only supports grouping

The total number of entities in the whole library can only be obtained through the query function, and the text needs to be split due to the length of the vectorization. For example, the text content of a file needs to be divided into 10 pieces into the database. At this time, the database result set returned by the search contains 10 pieces. In fact, the 10 pieces are the content of a file, and the result set cannot be combined by grouping.

In the old days, elasticsearch didn't store vectors, so we could store all the text data in a single record, and we could store the entire contents of a file in a single record, without the need for shards

2. The total number of entities after the search cannot be directly obtained for each hybrid search, full-text search, text matching, etc

Search doesn't have a direct way to get the total number of returned entities, so it's impossible to quickly and accurately know how many entities were hit. If you need to get the total number of entities corresponding to the current search condition, you need to set a particularly large topK and use the search iterator to realize it. Sometimes the database data is very large, and the number of hit records returns dynamic data results according to the input filtering condition, and different inputs return more or less entities. Do not know how to set a reasonable topK size and batchSize size

If the number of known database records is 8000, set the topK size to 10000 and batchSize to 50, the test search iterator has performance problems, and it takes an average of 4s to return the results. By contrast, elasticsearch has a direct method to get the total number of search results getHits().getTotalHits().

3. The search does not support highlighted text

Full-text search and hybrid search don't support highlighted text like es and need to be implemented manually. It is recommended to match the input text and the content in the library based on the tokenizer.

4. The search results cannot be sorted

Default sorting by similarity cannot be achieved like es sorting the results by the corresponding field in ascending and descending order

5. Hybrid search does not support iterator search

[yhmo]

1. get the total number of entities in the library
   Why not use count(*) to get the number of entities of each collection?

QueryResp countR = client.query(QueryReq.builder()
        .collectionName(collectionName)
        .filter("")
        .outputFields(Collections.singletonList("count(*)"))
        .consistencyLevel(ConsistencyLevel.BOUNDED)
        .build());
System.out.printf("%d rows persisted\n", (long)countR.getQueryResults().get(0).getEntity().get("count(*)"));

2. get the total number of returned entities by search/hybridSearch
   SearchResp returns a 2-d list, the inner list is the nearest entities of a terget vector, the size of the list is the total number of returned entities.

HybridSearchReq hybridSearchReq = HybridSearchReq.builder()
        .collectionName(COLLECTION_NAME)
        .searchRequests(searchRequests)
        .ranker(new WeightedRanker(Arrays.asList(0.2f, 0.5f, 0.6f)))
        .topK(5)
        .consistencyLevel(ConsistencyLevel.BOUNDED)
        .build();
SearchResp searchResp = client.hybridSearch(hybridSearchReq);
List<List<SearchResp.SearchResult>> searchResults = searchResp.getSearchResults();
for (int i = 0; i < NQ; i++) {
    System.out.printf("============= Search result of No.%d vector =============\n", i);
    List<SearchResp.SearchResult> results = searchResults.get(i);
    System.out.printf("Number of returned entities: %d\n", results.size());
}

[liaozhiyou]

I found that a search or hybrid search would return results based on the topK parameter, not the total number of hits in the library, for example, topK(5) would return only 5 of 100 hits in the database. In many cases, I don't know how many I hit. I don't know exactly how many entries in the library will be hit for each different input

[yhmo]

Some search inputs might hit all the items in the collection, the number could be a billion. RPC transfer bandwidth is not unlimited, so the maximum value of topK is limited to 16384.
Maybe we can define a new interface like "dry_run_search()" for some special purpose.