Qdrant Multitenancy

Multitenancy is how you isolate data across multiple users or tenants within a single Qdrant deployment.

The question to ask is: how many tenants, and how unevenly sized are they? That answer picks the isolation strategy.
Understand the three isolation levels before choosing: payload-based, shard-based and collection-based.
For almost everyone the right default is a single collection partitioned by payload, NOT a collection per tenant.

Many Small Tenants (Default: Payload Partitioning)

Use when: you have many tenants of roughly similar, modest size. This is the recommended default for most users.

One collection holds every tenant. A payload field marks ownership, and a filter on that field at query time is what isolates each tenant's results.

Create a keyword payload index on the tenant field with is_tenant=true (the flag requires v1.11+). is_tenant tells Qdrant the field identifies tenants, so each tenant's vectors are stored together and served by sequential reads. Check .
At query time, isolate each tenant with a must filter on the tenant field. Without it, a query searches every tenant's data. Check Payload-based multitenancy.
With this strategy, the indexing speed might become a bottleneck at scale because every tenant indexes into the same collection. To avoid this, you can disable the global HNSW creation (for the entire collection) and only build per-tenant indexes: set m=0 and payload_m to a non-zero value. Although this accelerates the indexing process, keep in mind that requests without a tenant filter will become slower as they must scan all groups. So only make this trade if you hit the bottleneck and cross-tenant search is rare. Calibrate performance.