We’re building a multi-tenancy system. Each tenant will manage their own collections with different properties.
As the number of the tenants growing, the total number of the collections will reach 1000 soon.
As I know, the multi-tenancy config of weaviate collection is based on the same collection shared by different tenants which is not the same with us.
How can I fix it? Increase the limit of the MAXIMUM_ALLOWED_COLLECTIONS_COUNT? but it’s not recommended.
Good morning @Charlie_Chen and welcome to the community — it’s great to have you here! We’re excited to help however we can.
You can absolutely create as many tenants as you want. The only real limit is your resources associate with DB — Weaviate can handle millions in tenants.
Now about collections: it’s generally recommended not to go over 1,000 of them. But tenants are different — they live within a collection. So if you’re using the same schema across multiple users or use cases, it’s much better to create one global collection and use tenants inside it. Each tenant is isolated, own shard, and pretty much behaves like its own collection — but it’s faster, more efficient, and easier to manage.
For example, say you’re building a chatbot app. Each of your users gets their own chatbot. Instead of creating a separate collection for every single user (which could really hurt performance), you’d just create one chatbot collection and make each user a tenant. Since all chatbots likely use the same schema, this setup works perfectly — you can scale to millions of users, and each tenant stays separate.
The main takeaway: avoid creating too many collections; focus on using tenants inside a shared collection when the schema is the same.
If I understood you well, you have a lot of users and in each user “collection” would be tenants, if this is the case - I would look into the schema plan again from different perspective. I am not sure really what exactly your use case.
One last note — if you’re planning to run in production at some point or test on high scale, make sure your setup includes multiple nodes and doesn’t rely on just one. Also, Weaviate is now at version 1.32.1 — you can check out the latest release notes here:
Hope this clears things up!
Best,
Mohamed Shahin
Weaviate Support Engineer
(Ireland, UTC±00:00/+01:00)
In my case — a low-code platform — each tenant can create their own collections, each with a different schema. That means tenants may define completely different sets of properties for their collections.
The only constraint I can enforce is the maximum number of collections each tenant can create — for example, 100 per tenant. But as you can imagine, with just 10 tenants, this could easily scale up to 1,000 collections, which is not sustainable.
I’ve considered two potential workarounds, but both have clear downsides:
Single giant collection with a metadata text property:
I could serialize tenant-defined properties into a JSON string and store them in a single metadata text field. But this approach severely limits filtering capabilities — I won’t be able to query by individual properties.
Single giant collection with a metadata object property:
I could store tenant-specific properties as nested fields inside a single metadata object. However, as far as I know, Weaviate currently doesn’t support filtering on nested object properties.
Do you have any recommendations or best practices for handling this kind of multi-tenant, dynamic-schema scenario?
Hey - the big problems with many collections is that the Graphql schema needs to be rebuild everytime you add/remove a collection or restart weaviate and the more collections you have the longer it will take.
I think the only way around this is to disable GraphQL using the `DISABLE_GRAPHQL` env var (this needs a restart). If you’re using our Python/TS clients everything will continue to work, but our old java/go clients are not supporting GRPC yet. There is already a beta for java with GRPC support out, but it does not support all features yet: Release 6.0.0-beta3 - Custom TrustStore, Fat JARs, Metadata Fields · weaviate/java-client · GitHub
