What factors should drive the decision to split data across multiple collections versus one collection with a discriminator payload field?

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.

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.