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.