Independent scaling and config needs versus per-collection overhead
The decision comes down to whether the data subsets need independent configuration or scaling, versus whether the overhead of managing many collections is justified. Use a shared collection with a discriminator payload field when the subsets share the same vector dimension, distance metric, and HNSW parameters, when queries are scoped by the discriminator, and when the number of subsets is large (hundreds to thousands). This is the standard multitenancy pattern: one collection, a tenant_id payload field marked with is_tenant=True, a tenant filter on every operation, and payload indexes to keep filtered queries fast. It scales because the collection is a single index, the segments are shared, and the memory overhead is the same as for a single-tenant collection of the same total size. The official Qdrant guidance explicitly recommends this pattern over one-collection-per-tenant because per-tenant collections do not scale past a few hundred and waste resources on the fixed per-collection overhead.
Use separate collections when the subsets differ in any immutable property of the collection. The immutable properties are the vector size, the distance metric, the HNSW parameters (m, ef_construct), the quantization scheme, and the collection-level configuration. If two subsets use different embedding models, they need different vector sizes and therefore different collections. If they use the same model but one needs high recall (higher m, higher ef) and the other is latency-sensitive (lower ef), they can technically share a collection but the parameters are collection-level, so you cannot tune them independently - separate collections give you that freedom. If they differ in retention policy, replication factor, or shard count, separate collections let you configure each. The other factor is query routing: if queries are scoped to a subset, both a shared collection with a filter and a separate collection can route efficiently, but the separate collection avoids the fan-out entirely because the query only touches one collection's segments. If queries span subsets (e.g. a global search across all tenants), a shared collection with a filter is more natural because the filter can be omitted to search all.
Shared collection with discriminator: same vector size, metric, and HNSW config across subsets; scoped queries use a filter; scales to thousands of subsets.
Separate collections: different vector size or metric; different HNSW or quantization config; different retention or replication; per-subset scaling; easier to drop or migrate one subset.
Overhead of separate collections: each collection has its own segments, indexes, and optimizer state, which consumes memory and CPU even when idle.
Query routing: scoped queries are cheapest with a shard key or a filter; a global query across all subsets is cheapest with a shared collection.
Operational complexity: many collections means more to monitor, back up, and migrate; a single collection is simpler to operate.
Threshold: the practical limit for shared collection is around 10,000 tenants; beyond that, consider tiered multitenancy with custom sharding.
Compliance: if subsets must be physically separated, separate collections are the only option.
The trade-off is between flexibility and operational overhead. A shared collection is simple and scales to many subsets, but it forces all subsets to share the same immutable config. Separate collections give each subset its own config but multiply the operational surface: more collections to monitor, more indexes to build, more segments to optimize, and more names to manage. The common mistake is to create one collection per tenant because it feels cleaner, and then discover that a few thousand collections exhaust the node's memory and slow down the cluster's metadata operations. The second mistake is to share a collection across subsets that need different embedding models or metrics, which is technically impossible because those are immutable per vector. The third mistake is to put everything in one collection and filter, without a payload index on the discriminator, which forces a scan on every query. The fourth mistake is to assume that sharding alone solves the tenant isolation problem - sharding is about distribution, not isolation, and isolation in a shared collection comes from the application's filters. Version note: the is_tenant flag and the tiered multitenancy features (custom sharding per tenant) were added in recent Qdrant releases. If you are on an older version, the multi-tenant pattern may not have the same optimizations, and the practical threshold for the number of tenants in a shared collection may be lower.
Version-dependent: the is_tenant flag, the tiered multitenancy pattern, and the custom sharding API have evolved across Qdrant releases. The recommended threshold for shared vs separate collections depends on the version's optimizations for tenant-scoped queries. If you are designing a system with a large number of tenants, verify the version's multitenancy support and benchmark the tenant-scoped query latency with your actual tenant distribution.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
