Multi-Tenancy Patterns

Overview

Multi-tenancy patterns enable SaaS applications to serve multiple customers from a single vector database deployment while maintaining data isolation, security, and performance.

Approaches

1. Collection Per Tenant

Pattern: Each tenant gets own collection

Pros:

• Complete isolation
• Easy backup/restore per tenant
• Independent scaling

Cons:

• Management overhead (1000s of collections)
• Resource inefficiency
• Higher operational complexity

2. Partition Per Tenant

Pattern: Single collection, partitions by tenant

Pros:

• Better resource utilization
• Easier management
• Native database feature

Cons:

• Partition limits
• Shared resources

3. Filter-Based

Pattern: Single collection, filter by tenant_id

Pros:

• Simplest implementation
• Best resource efficiency
• Easiest to manage

Cons:

• Must ensure filter on every query
• Potential security risk if filter forgotten
• Shared query resources

Implementation Example

# Filter-based
results = client.search(
    collection="documents",
    query_vector=embedding,
    filter={"tenant_id": current_user.tenant_id},
    limit=10
)

Security Considerations

• Access Control: Enforce at application layer
• Query Validation: Always include tenant filter
• Audit Logging: Track cross-tenant access attempts
• Encryption: Tenant-specific keys if needed

Choosing a Pattern

Collection-per-tenant: < 100 tenants, strict isolation needed Partition-per-tenant: 100-10K tenants, balanced approach Filter-based: 10K+ tenants, operational simplicity priority

Database Support

• Weaviate: Native multi-tenancy feature
• Qdrant: Collection sharding
• Milvus: Partition keys
• Pinecone: Namespaces

Pricing

Not applicable (architectural pattern).