06-reference/research

cortex search blast radius service partitioning

2026-08-15·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
snowflake-cortexphdatamulti-tenantrbacblast-radius

Service-Per-Business-Unit in Cortex Search Buys Real Availability and Throughput Containment, and Buys Leakage Containment Only If the Grant Graph Partitions Too

The question

"At a Fortune-2000 client-intelligence scale, does blast-radius containment argue for multiple Cortex Search services (service-per-business-unit) vs one mega-index, even within a flat shared-internal model?"

Promoted from the open follow-ups of the 2026-06-17 multi-tenant governance brief, which locked "flat internal, hard-walled external" for the client-intelligence plane and then asked whether that flat model should still be physically partitioned at the retrieval layer. Direct bearing on phData Data Solutions Architect / Forward Deployed Engineer delivery work.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The honest answer is yes, but for three reasons that are not the reason people say, and with one condition that most implementations will fail. Service partitioning contains three blast radii cleanly and provably. First, availability: a schema change to one business unit's source query forces a full re-embed and index rebuild of whatever service it belongs to. In a mega-index that means one team's pipeline edit re-embeds the entire corporate corpus and leaves every other business unit stale or degraded for the duration. Partitioned, it is one business unit's problem. Second, throughput: 20 queries per second is a per-service ceiling, and one enthusiastic business unit rolling out a chat surface will 429 everyone else off a shared index. Partitioned, each unit gets its own bucket, up to the account ceiling of 140. Third, offboarding and provability: dropping a service physically removes an index, which is a cleaner audit story than proving a filter predicate was always correctly applied.

The condition is that the grant graph has to partition too, and this is where the pattern usually collapses. Because Cortex Search runs with owner's rights and the enforced boundary is USAGE on the service object, partitioning contains leakage only if the callers are also partitioned. The moment a single company-wide assistant holds USAGE on all eight business-unit services, that agent is the union of all eight and the partitioning buys nothing on leakage. It still buys the availability and throughput containment above, which is not nothing, but the security argument evaporates. So the design rule is: partition services along entitlement boundaries and give each partition its own service role and its own calling application or agent. Do not partition along the org chart and then hand one super-agent every grant. That is theater, and an auditor who understands owner's rights will say so.

What partitioning does not contain, stated plainly. It does not contain bad-document poisoning within a unit — a poisoned document inside a business unit still poisons every answer that unit's users get, and if the document is shared across units it is duplicated into each service and poisons all of them. It does not contain the failure mode the vault already flagged as dominant, which is ungoverned data entering the pipeline upstream of retrieval. It does not help when the question is genuinely cross-unit: a partitioned estate turns a single ranked retrieval into a fan-out across N services plus a client-side merge, and you lose the single global reranker frame that made the scores comparable in the first place. That last item is the real cost of partitioning and it is a retrieval-quality regression, not an ops inconvenience. Cross-unit relevance dilution is a genuine argument for partitioning, but it is a quality argument wearing a security costume; it should be argued on its own merits.

The threshold, since the answer is conditional. Partition when any one of these holds: distinct entitlement populations with distinct calling applications; aggregate query load approaching 20 queries per second on a shared index; materially different refresh cadences or different rates of source-schema churn between units; or one unit carrying a sensitivity tier (protected health information, nonpublic personal information, licensed third-party feeds under redistribution terms) that the others do not. Keep one index when a single assistant serves everyone, load is comfortably under 20 queries per second, and cross-unit questions are common — in that shape you pay N× operational overhead for zero enforced isolation. On count, stay in single digits: seven services exhaust the account-wide 140 queries-per-second pool as a shared resource, and every service is another refresh orchestration, another target-lag policy, and another object in the fan-out. Service-per-team at forty teams is the failure mode on the other side. And check document overlap before committing: if more than roughly a quarter of the corpus is shared across units, the duplicate embedding and per-gigabyte serving tax plus fan-out complexity starts to favor one index with a genuinely trusted, non-agent application layer supplying the filter.

Why this is in the vault

It resolves an open follow-up from [[2026-06-17-multi-tenant-governance-shared-vector-store]] that gates the retrieval-layer design of the client-intelligence platform, and it corrects [[2026-04-28-snowflake-enterprise-knowledge-management]], which has been circulating an unqualified "service per business unit" recommendation into phData advisory framing without the owner's-rights caveat that determines whether the pattern actually contains anything.

Open follow-ups

Related

Sources

Vault:

Web (primary — fetched and read 2026-08-15):

Web (secondary — via search result summaries, not independently fetched):