Tenant isolation · per-customer indexes
Embed retrieval inside your own product
You're shipping a SaaS that needs vector retrieval per customer. Each tenant must see only their own data; quotas, API keys, and roles must be enforced inside the retrieval layer, not bolted on at your gateway.
Serve thousands of tenants from a single deployment, each with complete data isolation, without proportional infrastructure cost.
01
One tenant manager, many indexes
Each customer gets isolated indexes under their tenant ID. The manager enforces hard isolation at the storage and query layer.
02
Per-tenant API keys and RBAC
Mint argon2id-hashed keys per tenant. Admin / Editor / Viewer roles built in. Per-tenant quotas prevent noisy neighbours.
03
Single deploy, many customers
Run one cluster, route by tenant. No per-customer infra to provision.
Best fit when
- Your customers must never see each other's data. Strict isolation is a requirement.
- You want tenant lifecycle (create / suspend / delete) as a first-class concept
- You want the choice between shared infra and dedicated indexes per tenant
- You'd rather not build RBAC, quotas, and key management yourself
Wrong choice when
- Your tenants share one document library with row-level visibility filters rather than isolated indexes
- Your tenants need direct admin access to a separate dedicated cluster each
- You need cross-tenant federated search (we deliberately don't allow it)
Per-tenant
indexes · keys · quotas
Hard
isolation by design
RBAC
Admin / Editor / Viewer