One large enterprise tenant has 100x more data than a typical tenant in your shared multitenant collection. What problems could this cause, and how would you address them?

The problems fall into three categories: shard imbalance, resource contention, and operational impact. Shard imbalance: with custom sharding, each tenant is placed on a shard, and a tenant with 100x the data of others will make its shard much larger than the rest. That shard will have more segments, more memory usage, longer index builds, and potentially longer query latency. Resource contention: the large tenant's queries and writes consume more CPU and I/O, which can affect the other tenants on the same node - the classic noisy neighbor problem. Operational impact: the large tenant's data will dominate backups, snapshots, and reindexing, and a problem with that tenant's data (a corrupted segment, a bad batch import) can affect the shared collection's availability. The fix is to isolate the large tenant: either by giving it a dedicated shard (so its data is on its own shard and its queries do not compete with others on the same shard), or by giving it a dedicated collection (so it has its own segments, indexes, and optimizer state, and can be tuned independently).

The mechanism that makes isolation effective is that Qdrant's resource consumption scales with the number of segments and the size of the index. A shard with 100x the data has 100x the segments (or larger segments), which means more memory for the HNSW graph and payload indexes, more CPU for traversal, and more I/O for disk-based access. By giving the large tenant a dedicated shard or collection, you bound its resource consumption to its own shard and prevent it from affecting others. A dedicated collection also lets you tune the large tenant's configuration independently - higher m for better recall, more replicas for availability, a different quantization scheme - which is not possible in a shared collection where the configuration is collection-wide. The decision between a dedicated shard and a dedicated collection depends on whether the large tenant needs different configuration. If it does, a dedicated collection is the right choice. If it needs the same configuration but more capacity, a dedicated shard (or several shards) within the shared collection is sufficient. In both cases, the tenant's data must be migrated, which requires a plan for moving the data without downtime.