Multi-Tenant RAG Isolation

For SaaS RAG products with per-tenant knowledge bases (customer documents, internal data), isolation is a real concern. Cross-tenant data leakage via search is a class of incident you don't want. Three patterns handle isolation differently.

Patterns

• Per-tenant collection: qdrant.create_collection(f"kb_{tenant_id}"). Each tenant's vectors live in their own collection. Search query targets specific collection. Strongest isolation; some metadata overhead per collection.
• Shared collection + payload filter: all vectors in one collection, each with tenant_id in payload. Search filters via filter={"must": [{"key": "tenant_id", "match": {"value": tid}}]}. Cheaper at scale; correctness depends on every query applying filter.
• Per-tenant cluster: separate Qdrant instance per tenant. Strongest isolation; high ops cost; only for sensitive customers.
• Hybrid: per-tenant collection for paid tiers, shared+filter for free tiers.

Ops

• Tenant onboarding: collection created on tenant signup; ingest pipeline scoped to that collection
• Tenant offboarding: DROP COLLECTION on cancellation; satisfies GDPR right-to-erasure cleanly
• Backups: snapshot per collection; restore independently
• Quotas: per-collection size limits; alert before tenant hits cap
• Per-tenant index size: track for capacity planning

Compliance

For regulated industries (healthcare, finance, legal):

• Per-tenant collection makes audit easier — "show me all data for customer X" is one collection dump
• GDPR right-to-erasure is one DROP statement
• Per-tenant encryption keys possible (advanced; needed for highest sensitivity)
• Audit log: every cross-collection query logged

Verdict

For multi-tenant RAG, per-tenant collection in shared Qdrant is the right default. Strongest isolation with manageable ops cost. Shared+filter only when you have many small tenants (10K+) where collection metadata overhead matters. Per-tenant cluster only for highest-sensitivity customers willing to pay for it.