When should Qdrant tenants be separated by payload filter rather than by separate collections?

## Two shapes **Collection per tenant.** Each tenant gets its own collection, its own vector index, its own configuration. Isolation is structural; deleting a tenant is dropping a collection. **Payload partitioning.** One collection holds everyone. Every point's payload carries `tenant_id`, and every query carries a filter on it. ## Why payload partitioning is the default A collection is not free. It has segments, an index structure, optimizer work, and memory that does not amortise across tenants. Multiply that by a few thousand tenants — many of which hold a few hundred points — and the fixed overhead dominates the actual data. Payload partitioning turns the tenant boundary into a filter, which is a thing Qdrant is specifically built to make fast. The mechanism that makes it work is the tenant-aware payload index: create the keyword index on the tenant field with `models.KeywordIndexParams(type=models.KeywordIndexType.KEYWORD, is_tenant=True)`. That flag declares the field to be the partition key, letting Qdrant organise storage so one tenant's points sit together instead of being scattered across the collection — which is what keeps a tenant-filtered query from paying for the whole collection's size. Related tuning exists in the collection's `hnsw_config`, where payload-aware links can be built for such a field so that traversal stays connected inside a tenant's subset. ## Where it breaks down Several situations push back toward separate collections: - **Skew.** One tenant holds 80% of the points. Their queries and their index maintenance affect everyone else's tail latency. A dedicated collection for the whale, payload partitioning for the long tail, is a legitimate hybrid. - **Divergent configuration.** Different vector dimensions, different distance metrics, a tenant that needs quantization and one that must not — none of these are per-point settings, so they force separate collections. - **Blast radius.** A corrupted or over-optimised collection affects every tenant in it. - **Compliance.** "Prove this customer's data is not stored with anyone else's" is answerable structurally and awkward to answer with a filter. - **Deletion economics.** Removing a tenant from a shared collection is `delete(points_selector=models.FilterSelector(filter=...))`, which is cheap to issue but leaves the segments to be reclaimed by the optimizer in the background. Dropping a collection is instantaneous and complete — a real advantage when you have a contractual deletion deadline. ## The security question This is the part that separates a considered answer from a shallow one. Under payload partitioning, tenant isolation is a **property of every query your application issues**. One forgotten filter — a new endpoint, a debugging script, an analytics job, a `scroll` call written in a hurry — returns other tenants' data with no error and no signal. Structural isolation has no equivalent failure. The mitigation is architectural, not incidental: no application code constructs a raw Qdrant request. All reads go through one repository layer that takes the tenant from the request context and injects the filter itself, with the underlying client never exposed. Then add a test that asserts a query built without a tenant context fails rather than returning everything. Also apply the filter to writes and deletes — a `set_payload` or `delete` scoped by a filter that omits the tenant field is destructive across tenants. ## Choosing A workable default: start with payload partitioning; promote a tenant to its own collection when it is large enough that its behaviour is visible to others, or when a contract demands structural separation. Design for the promotion path from day one — keep the tenant id in the payload even in dedicated collections, and route reads through a resolver that maps tenant to collection, so moving one tenant is a data migration rather than a code rewrite. What you should never do is choose per-tenant collections "for safety" without counting them. Thousands of near-empty collections is a memory and operations problem that arrives quietly and is expensive to undo.