qdrant-tenant-scaling
Guides Qdrant multi-tenant scaling. Use when someone asks 'how to scale tenants', 'one collection per tenant?', 'tenant isolation', 'dedicated shards', or reports tenant performance issues. Also use when multi-tenant workloads outgrow shared infrastructure.
Install
With your agent
Install OMGSkills skill "qdrant/skills:skills/qdrant-scaling/scaling-data-volume/tenant-scaling" into this agent's normal skills directory: call the OMGSkills MCP get_install_plan tool for your agent and run the script it returns (it installs only the pinned commit and verifies SKILL.md), and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.
Manual command
git clone https://github.com/qdrant/skills /tmp/skills && ln -s /tmp/skills/skills/qdrant-scaling/scaling-data-volume/tenant-scaling ~/.claude/skills/qdrant-tenant-scalingFrom README
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. "Isolated" tenant queries — each tenant only ever sees its own data, with good performance — is the default outcome of payload filtering (istenant=true) in a single shared collection. It does not require separate collections. Separate collections only apply to the legal/compliance case, not as a way to get isolation. Understand multitenancy patterns 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 and Calibrate performance for best practices on indexing and query performance.