How do you isolate tenants in a shared vector index?

Three positions on one axis

Tenant isolation in retrieval is a single spectrum with three practical stops, and the interview is about knowing why you would sit at each.

Strategy	Isolation	Where it hurts
Index per tenant	Strongest; a wrong filter cannot cross a boundary	Fixed cost and memory floor per index, thousands of tiny indexes, per-tenant tuning and upgrade fan-out
Namespace or partition within one deployment	Queries are routed, not filtered; deletion is a partition drop	Shared resource pool, so noisy neighbours remain; isolation is a correct-routing guarantee, not a physical one
One index, tenant identifier as a filter	Cheapest, one thing to operate and tune	Every query's correctness depends on a predicate; small tenants lose recall; blast radius is everyone

The reason to prefer routing over predicates is not only security. Approximate nearest-neighbour search over a graph explores a neighbourhood; if the tenant you are filtering to holds a thousandth of the rows, the walk spends most of its effort on vectors it must discard and can strand in regions with no permitted neighbour, so measured recall falls even though the filter is logically correct. Compensating means raising search effort per query, which is a latency and cost tax you pay forever. Putting each tenant in its own partition converts that selectivity problem into a routing decision made before the search starts, and the graph you then traverse contains only rows that count.

That is the argument to lead with, because most candidates reach for isolation on trust grounds and stop. The engineering case is that a tenant filter is the one filter you can predict will be maximally selective.

Noisy neighbours in a vector store are specific things

Say what the contention actually is. A graph index wants to be resident in memory; a single tenant with ten million chunks in a shared deployment will occupy the page cache and push everyone else's hot vectors out, so unrelated tenants see tail latency they cannot explain. Index building and compaction is the second channel: one tenant's bulk migration saturates write throughput and CPU, and the compaction it triggers rewrites segments that other tenants' queries are reading. The third is anything with a shared budget — an embedding endpoint's rate limit, a reranker's GPU queue, a connection pool. Per-tenant quotas and admission control matter more here than in most systems, because a single tenant's re-ingest is not a gentle ramp, it is a step change.

Rebuild time is the operational one that surprises people. In a shared index, re-embedding because one tenant changed model or chunking strategy means touching a structure everyone depends on, and you cannot roll it out per tenant unless the query layer can point different tenants at different index generations. If you expect tenants to be on different pipeline versions — and in enterprise sales you will — partitioning is not a nicety, it is what makes the roadmap possible.

Blast radius is about writes, not reads

The read-side leak is what reviewers ask about, and it reduces to one question: can a query reach the store without a tenant constraint? The mitigation is architectural rather than diligent — resolve the tenant from the authenticated principal in a single place, never from a request parameter, and make the untenanted call unexpressible in the client you hand to feature teams.

The write-side risk is larger and less discussed. A delete-by-filter with a mistyped predicate, a backfill that computes the tenant identifier from the wrong field, a migration script run without a scope: in one shared index each of these is a multi-tenant incident, and none of them are prevented by read-path filtering. Per-tenant partitions bound the damage to one customer and, just as usefully, make restore meaningful — restoring one tenant from backup is a partition-level operation instead of a surgical extraction from a structure whose rows are interleaved. If you are asked to justify partitions to someone counting infrastructure cost, this is the argument that lands, because it is expressed in recovery time rather than in principle.

The same asymmetry drives the contractual operations. Export a tenant's corpus, delete a tenant on termination with something you can attest to, pin a tenant's data to a region, give a tenant its own encryption key: every one of these is a configuration change with a partition and a bespoke project without one.

What a shared embedding model does and does not leak

Be precise here, because both the alarmist and the dismissive answers are wrong.

Inference through a shared frozen model leaks nothing by itself. It is a deterministic function; running one tenant's text through it stores no state and leaves no residue for the next caller. Anyone claiming otherwise is confusing inference with training.

What does leak is anything that accumulates across tenants. Fine-tuning or continued pre-training on tenant corpora writes their content into weights that every tenant then queries, and no query-time filter can retract it — this is the reason to keep tenant data in retrieval rather than in training, and it applies equally to a reranker or a distilled model. A cache keyed by content hash in front of the embedding service is an existence oracle: a suspiciously fast response tells you someone else has embedded that exact string. Corpus-level statistics are the subtle one — in hybrid search, term frequencies computed across a shared index mean a tenant's scoring is influenced by other tenants' vocabulary, and a determined tenant can probe rare-term behaviour to infer what the wider corpus contains. If that matters to you, the statistics have to be computed per partition, which is another reason the partition boundary and the scoring boundary should be the same boundary.

One further point earns credit because it is often missed: an embedding is not a one-way hash. Approximate source text can be recovered from a vector, particularly for short passages, so vectors deserve the same classification and the same handling as the documents they came from. "It is only embeddings, not the text" is not a valid argument for relaxing isolation, and a reviewer who knows this will treat the claim as disqualifying.

Deciding per tenant rather than once

The answer that reads as experienced is that this is not one choice for the whole product. Large or contractually demanding tenants get their own index; the long tail shares one, partitioned by namespace; a handful with residency or key-management requirements get their own deployment in their own region. What makes that affordable is a routing layer between the application and the store that resolves a tenant to a physical location, index generation and pipeline version, so a tenant can be promoted from shared to dedicated as a migration rather than a rewrite. Build that indirection before you need it, because the point at which you need it is the point at which a signed contract is waiting on it.