Multitenancy with dynamic vector config

[oeway]

Hi,

I am trying to create a system where user can create their own collection (with different vector size etc.). After reading the qdrant documentation and github issues, it seems the best way forward is to create a single collection and use payload to partition the collection for different users. However, since the vector size are also dynamic in my case, it seems difficult to work with a single collection. I was hoping to use the named vector support to get around, so each user can have their own unique vector name, to store their own vector config. But it seems the vector_config cannot be updated after creating the collection.

Is this the right way to go? Any idea on how to support dynamically adding new vector config to an existing collection?

[timvisee]

However, since the vector size are also dynamic in my case, it seems difficult to work with a single collection.

In that case it'll not be possible to use the same collection. You can only partition in the same collection if the vector configurations are exactly the same.

I was hoping to use the named vector support to get around, so each user can have their own unique vector name, to store their own vector config. But it seems the vector_config cannot be updated after creating the collection.

Correct. Named vectors are static, and are not intended to be dynamic.

For example, imagine having 1000 named vectors, if only specifying one of them in each point that would be quite wasteful.

Is this the right way to go? Any idea on how to support dynamically adding new vector config to an existing collection?

So, dynamically adding a new vector to a collection is not really possible at this time.

For this specific case I'd recommend to use separate collections.

[oeway]

Thanks for the quick response!
Ok, so then it won't be scalable to many users with too many collections? Is there any performance tips for such case, e.g. creating many collections (1000+) with small or large number of points?

[timvisee]

Is there any performance tips for such case, e.g. creating many collections (1000+) with small or large number of points?

Not really, other than we usually recommend to not use it. Though I understand you might not really have a different choice.

Could you elaborate on what you're trying to build exactly? Maybe there's a different way of achieving the same goal.

[oeway]

We are working on image and text based multimodal search for the bioimage model zoo (https://bioimage.io) in life science, users upload models to our site, and some of them are embedding models which can create embedding vectors, we would like to enable image-based semantic search where user upload an image and search across image datasets we have. Since the model are provided by the users, we cannot determine in advance the vector size. I like a lot what qdrant's performance, documentation and the rich client library support, has already implemented a demo on top of qdrant, but later I noticed this issue. It would be a pity that I will have to switch to other vector databases (maybe redis or pgvector since we have already been using it for other purposes in the project).

[timvisee]

Since many models have similar dimension counts you may partition different dimensionality across different collections, and use payload based multi-tenancy on different models that share the same number of dimensions.

I understand that's not a very satisfying solution, but it's probably the best you can do. I don't think we'll be able to implement dynamic vector sizes anytime soon, as it conflicts with internal assumptions.

You could use sparse vectors as dense vectors with a dynamic size, but I'd recommend against that. They're not very performant when using them that way.

What would be even better is if you could use the same dimensionality on all your searches with a single model. But as far as I understand that's not possible in your scenario.

[oeway]

Thanks! Correct, it seems not possible, we don't know what are the dimensions in advance, user may come up with a new model and we will need to recreate the whole vector store if we do that. So maybe we will either go for many collections or switch to another database. Hope you will support this in the future!