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.
git clone --depth 1 https://github.com/qdrant/skills /tmp/qdrant-tenant-scaling && cp -r /tmp/qdrant-tenant-scaling/skills/qdrant-scaling/scaling-data-volume/tenant-scaling ~/.claude/skills/qdrant-tenant-scalingSKILL.md
# 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/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/md/documentation/manage-data/multitenancy/?s=tiered-multitenancy) to promote large tenants to dedicated shards while keeping small tenants on shared shards. This optimizes resource allocation and performance for tenants of varying sizes. ## Need Strict Tenant Isolation Use when: legal/compliance requirements demand per-tenant encryption or strict isolation beyond what payload filtering provides. - Multiple collections may be necessary for per-tenant encryption keys - Limit collection count and use payload filtering within each collection - This is the exception, not the default. Only use when compliance requires it. ## What NOT to Do - Do not create one collection per tenant without compliance justification (does not scale past hundreds) - Do not skip `is_tenant=true` on the tenant index (kills sequential read performance) - Do not build global HNSW for multi-tenant collections (wasteful, use `payload_m` instead)
Qdrant provides client SDKs for various programming languages, allowing easy integration with Qdrant deployments.
Guides Qdrant deployment selection. Use when someone asks 'how to deploy Qdrant', 'Docker vs Cloud', 'local mode', 'embedded Qdrant', 'Qdrant EDGE', 'which deployment option', 'self-hosted vs cloud', or 'need lowest latency deployment'. Also use when choosing between deployment types for a new project.
Guides embedding model migration in Qdrant without downtime. Use when someone asks 'how to switch embedding models', 'how to migrate vectors', 'how to update to a new model', 'zero-downtime model change', 'how to re-embed my data', or 'can I use two models at once'. Also use when upgrading model dimensions, switching providers, or A/B testing models.
Guides Qdrant monitoring and observability setup. Use when someone asks 'how to monitor Qdrant', 'what metrics to track', 'is Qdrant healthy', 'optimizer stuck', 'why is memory growing', 'requests are slow', or needs to set up Prometheus, Grafana, or health checks. Also use when debugging production issues that require metric analysis.
Diagnoses Qdrant production issues using metrics and observability tools. Use when someone reports 'optimizer stuck', 'indexing too slow', 'memory too high', 'OOM crash', 'queries are slow', 'latency spike', or 'search was fast now it's slow'. Also use when performance degrades without obvious config changes.
Guides Qdrant monitoring setup including Prometheus scraping, health probes, Hybrid Cloud metrics, alerting, and log centralization. Use when someone asks 'how to set up monitoring', 'Prometheus config', 'Grafana dashboard', 'health check endpoints', 'how to scrape Hybrid Cloud', 'what alerts to set', 'how to centralize logs', or 'audit logging'.
Different techniques to optimize the performance of Qdrant, including indexing strategies, query optimization, and hardware considerations. Use when you want to improve the speed and efficiency of your Qdrant deployment.
Diagnoses and fixes slow Qdrant indexing and data ingestion. Use when someone reports 'uploads are slow', 'indexing takes forever', 'optimizer is stuck', 'HNSW build time too long', or 'data uploaded but search is bad'. Also use when optimizer status shows errors, segments won't merge, or indexing threshold questions arise.