In Pinecone, how do you isolate thousands of tenants — namespace or index per tenant?

## Framing the decision The question is really about which Pinecone object carries the tenant boundary, and there are three candidates: a separate index per tenant, a namespace per tenant inside a shared index, or a single shared pool with a tenant attribute on each record. They differ in cost, in blast radius, and in what queries become easy or hard. ## Index per tenant An index is a heavyweight object. Creating one is a control-plane operation with real provisioning latency, it has its own immutable dimension, metric and spec, and projects have quotas on how many indexes they may hold. At thousands of tenants none of that works: signup would block on provisioning, you would exceed the quota, and every configuration change or migration becomes a loop over thousands of objects with partial-failure handling. What an index per tenant does buy is total separation — separate configuration, separate capacity, separate cost attribution, and a deletion that removes the whole object. That is occasionally the right answer, but only for a handful of tenants: a small number of very large enterprise customers with contractual isolation requirements, or tenants that genuinely need a different embedding dimension, a different metric, or storage in a specific region for data-residency reasons. Those are index-level properties, so a tenant that needs one of them cannot be served by a namespace at all. ## Namespace per tenant This is the default answer at scale, and interviewers expect you to reach it quickly and then discuss its limits rather than treat it as obvious. The advantages are concrete. A namespace comes into existence on the first upsert, so onboarding a tenant is a write with no provisioning step and no quota concern. A query is scoped to exactly one namespace and cannot see another's records, so isolation does not depend on the application remembering to attach a condition — a whole class of leak bug is structurally impossible rather than merely tested for. Offboarding is a single bulk operation: `index.delete(delete_all=True, namespace="tenant-a")` removes everything that tenant ever wrote, which matters when you have deletion obligations. And because every namespace shares the index's dimension and metric, scores are comparable if you ever do need to merge across them. The disadvantages are equally concrete. There is no cross-namespace query, so anything global — an internal admin search, a corpus-wide quality evaluation, a "find this document anywhere" support tool — must fan out one call per tenant and merge client-side. At thousands of tenants that is not a query, it is a batch job. Very small namespaces also mean each tenant's search quality is bounded by their own tiny corpus, which is a product question rather than a technical one but surfaces as "why does search feel worse for new customers". And because namespaces are minted implicitly, a bug in the tenant-id derivation creates a phantom namespace instead of raising an error, which is why the namespace string should come from one central function fed by a stable internal id, never a display name. ## Shared pool with a tenant attribute Keeping all tenants in one namespace and tagging each record with its tenant makes cross-tenant search a single call, which is the one thing namespaces cannot do. The price is that isolation now depends on every query path attaching the right condition — one code path that forgets it leaks another customer's documents, which is a far worse failure than a slow admin tool. For genuinely multi-customer data this trade is usually unacceptable. Where it does belong is *within* a tenant: use the namespace for the hard customer boundary and attributes for softer slices such as document type, source or date. That hybrid is what most mature designs converge on. ## The shape that usually wins A small number of indexes — one per embedding model, plus extras only where region or metric differs — with a namespace per tenant inside each, and metadata attributes for within-tenant structure. Tenant routing lives in one function that maps an internal tenant id to (index name, namespace), so the mapping can change later without touching call sites. Cross-tenant needs are served by an offline job that fans out, not by an online query path. ## Second-order concerns a lead should raise **Cost attribution.** On a shared index, per-tenant cost is not billed to you separately; if you must charge back, you need to attribute it yourself from query and ingest volume per tenant, which means instrumenting the routing layer from day one. **Noisy neighbours.** Tenants share the index's resources. Namespaces isolate *results*, not *capacity*, so one tenant's ingest storm or query flood is still your problem, and rate limiting belongs in your own service rather than being assumed from the partition model. **Skew.** Tenant sizes in real systems follow a power law. A design that works for the median tenant of a few thousand vectors may not suit the one holding tens of millions, and promoting that outlier to its own index later is a legitimate escape hatch — which is another reason routing must be indirect. **Migration.** Because dimension, metric and spec are immutable, a model upgrade is a new index and a full re-embed for every tenant. Plan that as a per-tenant backfill with progress tracked from namespace counts, and decide up front whether tenants cut over together or individually. ## Interview signal The weak answer picks one option and stops. The strong answer names the deciding factors — control-plane weight and quotas, structural versus filter-based isolation, and whether cross-tenant search is a real requirement — reaches namespace-per-tenant as the default, names the specific exceptions that force a separate index, and volunteers the second-order concerns of attribution, skew and migration.