AutoGineer
Generated banner for Qdrant Tenant Scaling
Generated logo for Qdrant Tenant Scaling

Qdrant Tenant Scaling

QdrantOfficialPublished by Qdrant

  • Skill
  • Guidelines
  • Data and AI
  • Apache-2.0
  • No issues found
Download ZIP

From the author

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.
— the description by Qdrant

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides architectural guidance for managing multi-tenant workloads in Qdrant. It emphasizes avoiding the anti-pattern of creating one collection per tenant, which fails to scale, and instead promotes using shared collections with payload filtering. It covers strategies for different scales, including payload partitioning for up to 10k tenants, custom sharding for 100k+ tenants, and tiered multitenancy for handling uneven tenant sizes. It also clarifies when separate collections are appropriate, specifically for legal or compliance requirements rather than performance isolation.

What it does

  • Recommends payload filtering as the primary method for tenant isolation.
  • Provides scaling strategies for varying numbers of tenants (10k to 100k+).
  • Explains how to use custom sharding to localize tenant data to specific nodes.
  • Outlines tiered multitenancy for managing tenants with uneven data sizes.
  • Identifies specific compliance scenarios where separate collections are necessary.
  • Lists common anti-patterns to avoid when designing multi-tenant Qdrant systems.

When to use it

  • When designing a new multi-tenant architecture in Qdrant.
  • When experiencing performance issues in a multi-tenant Qdrant deployment.
  • When deciding between shared collections and separate collections for tenants.
  • When scaling beyond a few hundred tenants.
  • When needing to optimize resource allocation for tenants of varying sizes.

Advantages

  • Prevents resource exhaustion caused by excessive collection creation.
  • Improves query performance through effective indexing and sharding strategies.
  • Ensures proper tenant isolation without unnecessary architectural complexity.
  • Provides a clear path for scaling from small to very large tenant counts.
  • Helps maintain compliance while optimizing infrastructure costs.

Usage examples

“How should I structure my Qdrant collections for 50,000 tenants?”
The skill advises using a shared collection with payload filtering and implementing custom sharding based on tenant ID hash to localize data and improve performance.
“Should I create a new collection for every new customer to ensure their data is isolated?”
The skill explains that this is an anti-pattern that does not scale, and recommends using payload filtering for isolation instead.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/qdrant/qdrant-tenant-scaling/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip qdrant-tenant-scaling.zip -d .agents/skills

Documentation by Qdrant

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 (is_tenant=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.

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.

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 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 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 Per-Tenant Encryption or Legal/Compliance Isolation (Exception, Not the Default)

Use when: legal/compliance requirements demand per-tenant encryption keys or physical data separation — not merely "tenants shouldn't see each other's data," which payload filtering already guarantees on its own.

  • 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 treat "isolated" or "isolation" in a request as a reason to use separate collections — default query isolation comes from payload filtering (is_tenant=true) in a shared collection, not from separate collections

  • Do not skip is_tenant=true on the tenant index (kills sequential read performance)

  • Do not disable the global HNSW index (m: 0 with payload_m) by default: do it only when indexing speed is the bottleneck and cross-tenant search is rare, because global queries without a tenant filter get slower Multitenancy

Files

SKILL.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.

"Isolated" tenant queries — each tenant only ever sees its own data, with good performance — is the default outcome of payload filtering (is_tenant=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.

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.

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 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 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 Per-Tenant Encryption or Legal/Compliance Isolation (Exception, Not the Default)

Use when: legal/compliance requirements demand per-tenant encryption keys or physical data separation — not merely "tenants shouldn't see each other's data," which payload filtering already guarantees on its own.

  • 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 treat "isolated" or "isolation" in a request as a reason to use separate collections — default query isolation comes from payload filtering (is_tenant=true) in a shared collection, not from separate collections

  • Do not skip is_tenant=true on the tenant index (kills sequential read performance)

  • Do not disable the global HNSW index (m: 0 with payload_m) by default: do it only when indexing speed is the bottleneck and cross-tenant search is rare, because global queries without a tenant filter get slower Multitenancy

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Qdrant
Publisher
Qdrant (Official)
Source
qdrant/skills · skills/qdrant-scaling/scaling-data-volume/tenant-scaling · commit 9f55f6a
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Qdrant or Qdrant.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download qdrant-tenant-scaling.zip