Using a vector database

Multi-tenancy

2 min readChapter 14 of 25By Bipin Singh

If you build a product for many customers, each customer's vectors must stay invisible to the others. Multi-tenancy is about achieving that isolation while keeping costs and operations sane.

Three ways to separate tenants

Approach	How it works	Pros	Cons
Metadata filter	One shared collection; every record has `tenant_id`; every query filters on it	Simplest; efficient for many small tenants	Isolation depends on never forgetting the filter; big tenants affect small ones
Namespace / partition	The database keeps each tenant's data in its own partition within a collection	Stronger separation; queries only touch one tenant's data; easy per-tenant deletion	Feature varies by database; very many partitions can have overhead
Collection (or database) per tenant	Completely separate indexes per tenant	Strongest isolation; per-tenant settings and scaling	Operational overhead with many tenants; idle tenants still cost resources

Choosing

Many small tenants (thousands of SMB customers) → namespaces or metadata filtering.
Few large tenants (enterprise customers with big datasets and strict requirements) → collection or even cluster per tenant.
A mix → tier it: shared infrastructure for small tenants, dedicated resources for large or regulated ones.

Key idea

Make tenant isolation impossible to forget. Enforce the tenant filter in a single data-access layer — never rely on every developer adding it to every query.

Enforcing isolation in code

// Every search goes through this function; callers cannot omit the tenant.
async function searchForTenant(tenantId: string, queryVector: number[], k = 10) {
  if (!tenantId) throw new Error("tenantId is required");
  return vectorDb.search({
    collection: "documents",
    vector: queryVector,
    limit: k,
    filter: { tenant_id: tenantId }, // or: namespace: tenantId
  });
}

Back this up with tests that try to read another tenant's data and must fail.

Noisy neighbours

In shared setups, one huge or very busy tenant can slow everyone down. Mitigations include per-tenant rate limits, partitioning large tenants separately, and monitoring per-tenant latency.

Deleting a tenant

When a customer leaves, you need to remove all their data reliably. Namespaces and per-tenant collections make this a single operation; metadata filtering requires a delete-by-filter and then compaction. Plan for it from the start.

Watch out

For regulated customers, ask early about data residency and isolation requirements. Some will require dedicated infrastructure in a specific region, which rules out a single shared collection.

Written by Bipin Singh

Senior Full-Stack Engineer · AI & AWS. I build production search, RAG and AI systems on AWS and Postgres.

Work with me