Skip to content

CONCEPT Cited by 1 source

Per-tenant search instance

Definition

A per-tenant search instance is an isolated (storage, index) unit, one per tenant (agent, customer, session, language, region, …), created and destroyed at runtime, so the tenant's data never commingles with another tenant's data at the retrieval layer. At the retrieval tier, it is the direct analog of the one-to-one agent instance pattern at the actor tier.

Why not one big index with a tenant_id filter

The traditional single-index + WHERE tenant_id = … shape suffers the usual multi-tenant ills:

  • Cross-tenant leakage hazard — a forgotten WHERE clause leaks one customer's data to another; isolation is a policy rather than a structure.
  • Global index tuning — BM25 statistics (avgdl, idf), HNSW graph structure, chunk budgets are set across tenants; a noisy tenant can distort another's rankings.
  • Blast radius — reindex, schema change, or corruption touches all tenants.
  • Lifecycle coupling — tenant deletion requires scan-and-purge; you can't just drop the index.
  • Per-tenant configuration — hybrid-search tokenizer (porter vs trigram), match mode (AND vs OR), fusion method, reranking on/off cannot vary per tenant.

A per-tenant instance inverts each property: structural isolation, per-tenant index statistics, per-tenant blast radius, instance-drop deletion, per-tenant configuration.

Named in Cloudflare AI Search (2026-04-16)

"The new ai_search_namespaces binding lets you create and delete instances at runtime from your Worker, so you can spin up one per agent, per customer, or per language without redeployment."

"You can track this by creating an AI Search instance per customer. After each resolved issue, the agent saves a summary of what went wrong and how it was fixed. Over time, this builds up a searchable log of past resolutions."

— (Cloudflare, 2026-04-16)

Economics bet: the same bet Durable Objects make at the actor tier — a per-tenant unit is cheap because it's "zero idle cost," elastically scaled, platform-managed, created on demand.

Structural properties

  • Runtime-creatable: env.NAMESPACE.create({ id: "customer-abc123" }) at first appearance of a tenant; idempotent on re-create.
  • Runtime-destroyable: env.NAMESPACE.delete(id) purges the tenant's data in one operation.
  • Independently configured: each instance can have its own tokenizer, match mode, fusion method, reranking config.
  • Composable: cross-instance search (patterns/cross-index-unified-retrieval) queries multiple instances in one call, merging + ranking, so the per-tenant decomposition doesn't force per-tenant app code.

Relationship to account-per-tenant isolation

Per-tenant search instance is the retrieval-tier realisation of the same "isolation as structure, not as policy" thesis that concepts/account-per-tenant-isolation makes at the AWS-account tier. Different cost/flexibility tradeoff — a search instance is far cheaper than an AWS account, so per-session or per-conversation granularity is feasible.

Seen in

Last updated · 200 distilled / 1,178 read