# ILM vs routing for growing vector database with separate clients **URL:** \ **Category:** Elasticsearch\ **Tags:** ilm-index-lifecycle-management\ **Created:** [December 10, 2025, 3:49pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962 "2025-12-10T15:49:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Pablito77](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pablito77/32/146137_2.png) [@Pablito77](https://discuss.elastic.co/u/Pablito77)\ **Post date:** [December 10, 2025, 3:49pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/1 "2025-12-10T15:49:44Z")
Hello, I use elasticsearch as a vector db for 1024 dim vectors. My initial setup would be around 20 million vectors, but it may increase to 100 milion vectors over time. However i always prefilter the vector search to a specific client\_id - i have around 10k clients, they can have between 100 and +10k documents. The daily volume is about 300k writes and searches. I am wondering if it is better to use well known routing with static index of 20-30 shards or would you suggest to implement ILM policy with single shards and rollover after 30-40 GB. To sum up my conern is to implement ILM for growing index or routing to eliminate redundant shard searches. Thanks in advance for help! ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 10, 2025, 4:13pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/2 "2025-12-10T16:13:15Z")
Do you just add new documents or do you also perform updates and/or deletes? Do you have a specified retention period for your data set? ---
**Author:** ![Pablito77](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pablito77/32/146137_2.png) [@Pablito77](https://discuss.elastic.co/u/Pablito77)\ **Post date:** [December 10, 2025, 4:16pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/3 "2025-12-10T16:16:30Z")
I add new documents on a daily basis and i also update them and delete - it bases on the user action in the system. Retention period is not an issue, because this is only a database for ML. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 10, 2025, 4:20pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/4 "2025-12-10T16:20:03Z")
In that case I think ILM and time-based indices seem to be a bad fit as it complicates updates and deletes and you do not want to use it to manage retention (which is it’s main purpose). I would go with a reasonably large number of primary shards together with routing based on the client ID. ---
**Author:** ![Pablito77](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pablito77/32/146137_2.png) [@Pablito77](https://discuss.elastic.co/u/Pablito77)\ **Post date:** [December 10, 2025, 5:52pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/5 "2025-12-10T17:52:16Z")
Okay, Thank you for your opinion. I would probably do around 20 shards so they start with 5 GB and reach at most 30 GB. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 10, 2025, 5:56pm UTC](https://discuss.elastic.co/t/ilm-vs-routing-for-growing-vector-database-with-separate-clients/383962/6 "2025-12-10T17:56:39Z")
As your clients differ in size it is possible you will get an uneven shard size distribution, so it may be worthwhile going a bit higher on shard count for that reason. At least test it if you can.