qdrant-tenant-scaling

# What to Do When Scaling Multi-Tenant Qdrant Do not create one collection per tenant. Does not scale past a few hundred and wastes resources. One company hit the 1000 collection limit after a year of collection-per-repo and had to migrate to payload partitioning. Use a shared collection with a tenant key. - Understand multitenancy patterns [Multitenancy](https://skills.qdrant.tech/md/documentation/manage-data/multitenancy/) Here is a short summary of the patterns: ## Number of Tenants is around 10k Use the default multitenancy strategy via payload filtering. Read about [Partition by payload](https://skills.qdrant.tech/md/documentation/manage-data/multitenancy/?s=partition-by-payload) and [Calibrate performance](https://skills.qdrant.tech/md/documentation/manage-data/multitenancy/?s=calibrate-performance) for best practices on indexing and query performance. ## Number of Tenants is around 100k and more At this scale, the cluster may consist of several peers. To localize tenant data and improve performance, use [custom sharding](https://skills.qdrant.tech/md/documentation/scaling/distributed_deployment/?s=user-defined-sharding) to assign tenants to specific shards based on tenant ID hash. This will localize tenant requests to specific nodes instead of broadcasting them to all nodes, improving performance and reducing load on each node. ## If tenants are unevenly sized If some tenants are much larger than others, use [tiered multitenancy](https://skills.qdrant.tech/m...