What are the limits of a purely payload-filter-based multitenancy model, and at what point would you need to introduce dedicated shards or collections per tenant instead?

Payload-filter-based multitenancy works well when tenants are similar in size and access pattern, when the isolation requirement is logical, and when all tenants share the same collection configuration. It reaches its limits in four situations. First, a hot tenant: a tenant whose data or query volume is much larger than the others creates a hot shard and a noisy-neighbor problem. The payload filter does not help because all queries for that tenant hit the same shard, and the shard's resources are consumed by that tenant. Second, strict isolation: a tenant with a compliance requirement for physical isolation cannot be satisfied by a payload filter, because the data is on the same shard and the same node as other tenants. Third, configuration divergence: a tenant that needs a different embedding model, a different distance metric, a different HNSW configuration, or a different replication factor cannot be accommodated in a shared collection, because the configuration is collection-wide. Fourth, scale: a very large number of tenants (tens of thousands) with a long tail of small tenants and a few large ones makes the shared collection unbalanced, and the operational overhead of managing the tenants within one collection grows. At these points, the right move is to introduce dedicated shards (for the hot tenant, within the same collection) or dedicated collections (for the tenant that needs independent configuration or physical isolation).

The mechanism that determines when the shared model breaks is the distribution of tenant sizes and the resource model of the shard. A shard is the unit of resource allocation: its segments, its HNSW graph, its payload indexes, and its memory footprint are all shared by the tenants on that shard. If one tenant dominates the shard, the other tenants on that shard suffer. The payload filter isolates the data logically but not physically, so the noisy-neighbor effect is real. The threshold at which this becomes a problem depends on the size distribution: if the largest tenant is 10x the median, the shard imbalance is manageable; if it is 100x or 1000x, the hot shard becomes a bottleneck. The threshold for dedicated collections is different: a tenant needs a dedicated collection when its configuration must diverge (different model, metric, or HNSW config) or when its isolation requirement cannot be met by a filter. The threshold for dedicated shards is lower: a tenant can stay in the shared collection but get its own shard to avoid the noisy-neighbor effect. The two thresholds are independent: a tenant may need a dedicated shard without needing a dedicated collection, and vice versa.

The trade-off is between operational simplicity and tenant isolation. The shared collection is simpler but does not scale to extreme tenant distributions or strict isolation requirements. Dedicated shards and collections add operational overhead but address the limits. The common mistakes are: (1) keeping a 100x tenant in the shared collection and suffering the noisy-neighbor effect; (2) creating a dedicated collection for a tenant that only needs a dedicated shard, which adds unnecessary overhead; (3) not having thresholds, so the decision is made reactively during an incident; (4) not monitoring per-tenant resource usage, so the problem is detected late; (5) assuming the shared collection scales indefinitely, which it does not. Version note: custom sharding and the is_tenant flag have evolved across Qdrant releases. The practical threshold for the shared model depends on the version's optimizations and on the workload. Benchmark with your tenant distribution.

Version-dependent: custom sharding, the is_tenant flag, and the tiered multitenancy features have evolved across Qdrant releases. Verify the availability and behavior on your version, and benchmark with your tenant distribution.