Vector Multi-Tenancy
A tenant is a customer, team, or organization that uses your application. Multi-tenancy means one vector database serves many tenants while keeping each tenant's data private. A chat tool for a thousand companies must never show Company A's documents to Company B.
The Apartment Building Analogy
An apartment building shares one structure, one roof, and one plumbing system among many families. Each family keeps a private apartment with a locked door. Multi-tenancy follows the same pattern: shared infrastructure with strict separation.
Three Common Designs
DESIGN 1: Separate database per tenant
Tenant A -> Database A
Tenant B -> Database B
Strongest isolation, highest cost
DESIGN 2: Separate collection or namespace per tenant
One database
+-- Collection A
+-- Collection B
Strong isolation, moderate cost
DESIGN 3: Shared collection with a tenant filter
One collection
vectors tagged tenant_id = A or B
Lowest cost, needs careful filtering
| Design | Isolation | Cost | Best For |
|---|---|---|---|
| Database per tenant | Strongest | High | Few large clients with strict rules |
| Collection or namespace per tenant | Strong | Medium | Hundreds of tenants of mixed size |
| Shared collection with filter | Depends on code quality | Low | Thousands of small tenants |
The Filter Approach in Detail
Every stored vector carries a tenant ID in its metadata. Every query includes a filter that matches the caller's tenant ID.
STORED RECORD
vector: [0.12, 0.77, ...]
metadata: { "tenant_id": "acme", "doc": "handbook.pdf" }
QUERY FROM ACME USER
vector: [0.10, 0.80, ...]
filter: tenant_id = "acme"
RESULT: only Acme documents
Never trust the client to supply the tenant ID. The server must read the ID from the verified login session and add the filter itself.
Security Rules
- Enforce filters on the server: A missing filter equals a data leak.
- Test isolation: Write automated tests that query as Tenant A and confirm zero Tenant B results.
- Use scoped keys: Give each service the narrowest permissions it needs.
- Audit access: Log which tenant ran which query.
The Noisy Neighbor Problem
One heavy tenant can slow search for everyone in a shared system. Reduce the risk with a few controls.
- Set rate limits for each tenant.
- Cap the number of vectors each plan can store.
- Move very large tenants to dedicated collections or servers.
- Track latency by tenant to spot trouble early.
Index Performance With Filters
A shared collection with a restrictive filter can slow graph-based indexes, because the search wanders through many vectors that belong to other tenants. Databases with filter-aware indexes or partition support handle this better. Test your platform with realistic tenant sizes before launch.
Onboarding and Offboarding
ONBOARD A NEW TENANT
1. Create the tenant record
2. Create a collection or reserve a tenant ID
3. Set quotas and keys
4. Load initial documents
OFFBOARD A TENANT
1. Export data if the contract requires it
2. Delete vectors, metadata, and source files
3. Remove backups after the retention period
4. Record the deletion for audit purposes
Choosing a Design
Start with your isolation requirements. Regulated industries often demand separate collections or databases. Consumer apps with thousands of small accounts usually choose filters or namespaces. Many teams mix approaches: small tenants share a collection, while enterprise customers receive dedicated resources.
Multi-tenancy rewards careful design from day one. Decide your isolation level early, enforce it on the server, and test it often.