Design a Qdrant-backed search feature for a SaaS product with thousands of small customers, each with their own private dataset. What collection and sharding strategy would you use?

Question

Accepted Answer

For thousands of small customers, the right design is a shared collection with a tenant_id discriminator payload field, custom sharding by tenant, and a payload index on tenant_id marked with is_tenant=True. Each tenant's data is identified by the tenant_id field, and every query includes a filter on that field. Custom sharding co-locates each tenant's data on a single shard, so a tenant-scoped query hits one shard instead of fanning out to all shards. This is the combination that balances isolation with operational simplicity: the data is logically isolated by the filter, the query is efficient because it is routed to a single shard, and the operational overhead is one collection and a small number of shards rather than one collection per tenant. 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 overhead of each collection. The mechanism that makes custom sharding work is that the shard key is chosen by the application, not hashed from the point ID. When you create a shard key for a tenant and upsert points with that shard key, Qdrant places all of those points on the shard associated with that key. A query that specifies the shard key is routed to that shard only, so the query does not fan out. This is the key to scaling to thousands of tenants: without custom sharding, every query would fan out to all shards, and the coordinator's merge cost would grow with the number of shards. With custom sharding, the query cost is bounded by the shard's size, not by the total number of tenants. The tenant_id field is also marked with is_tenant=True, which tells the optimizer that this field is used for tenant scoping and enables optimizations in the index and query planning. The combination of custom sharding (for routing) and is_tenant (for indexing) is the recommended multi-tenant pattern for current Qdrant versions. One shared collection, not one per tenant: scales to thousands of tenants without per-collection overhead. tenant_id payload field: identifies which tenant each point belongs to. Custom sharding by tenant: co-locates each tenant's data on a single shard. is_tenant=True: marks the tenant field for index and query optimization. Query with shard key: routes to one shard instead of fanning out. Query with tenant filter: enforces logical isolation in the application. Payload index on tenant_id: keyword index for efficient filtering. Trusted service: the query is issued by a service that knows the tenant, never by the client directly. Tiered multitenancy: large tenants can be moved to dedicated shards or collections. The trade-off is between isolation and operational simplicity. A shared collection with filters provides logical isolation, which is sufficient for most SaaS products but not for tenants with strict physical-isolation requirements. Custom sharding improves query efficiency but requires the application to manage shard keys and to handle the case where a tenant grows large enough to warrant its own shard. The common mistake is to create one collection per tenant, which does not scale. The second mistake is to not use custom sharding, so every query fans out to all shards. The third mistake is to rely on the tenant filter alone without a payload index, which forces a scan on every query. The fourth mistake is to let clients query Qdrant directly, which means they could omit the tenant filter and see other tenants' data - the filter must be enforced by a trusted service. The fifth mistake is to not plan for a tenant that grows much larger than the others, which creates a hot shard. Version note: custom sharding and the is_tenant flag 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. from qdrant_client import QdrantClient, models

client = QdrantClient('http://localhost:6333')

# Shared collection with custom sharding by tenant.
client.create_collection(
    collection_name='tenant_data',
    vectors_config=models.VectorParams(size=768, distance=models.Distance.COSINE),
    sharding_method=models.ShardingMethod.CUSTOM,
    shard_number=4,   # start with a small number; add shards as tenants grow
)

# Create a shard key per tenant. Qdrant places all points with this key on
# the same shard.
for tenant_id in initial_tenants:
    client.create_shard_key('tenant_data', tenant_id)

# Index the tenant field for efficient filtering.
client.create_payload_index(
    collection_name='tenant_data',
    field_name='tenant_id',
    field_schema=models.KeywordIndexParams(type='keyword', is_tenant=True),
)

# Upsert with the shard key.
def upsert(tenant_id, points):
    client.upsert(
        collection_name='tenant_data',
        points=[
            models.PointStruct(
                id=p.id,

Design a Qdrant-backed search feature for a SaaS product with thousands of small customers, each with their own private dataset. What collection and sharding strategy would you use?

Shared collection with tenant_id discriminator and custom sharding by tenant

Design a Qdrant-backed search feature for a SaaS product with thousands of small customers, each with their own private dataset. What collection and sharding strategy would you use?

Shared collection with tenant_id discriminator and custom sharding by tenant

Scenario Questions

Follow-up Questions