VPOL study materials
VPOL study resources

Designing Tenancy for a Shared Analytics Platform

VPOL · Put your knowledge to work in context.

All case studies

Designing Tenancy for a Shared Analytics Platform

A platform team is building an internal analytics service for 14 business units. Each unit ingests its own data and runs queries against a shared compute cluster. Leadership wants a single deployment to reduce cost, but the security team requires that unit A cannot read unit B's data, and that a runaway query from one unit cannot degrade others. Current usage ranges from 2 queries per day for one unit to 40,000 per day for another. The team proposes one database, one schema, and a tenant_id column on every table, with row-level security enforced by the query engine. There is no per-tenant resource isolation in the proposal. Two units have regulatory obligations requiring data residency in a specific region; the cluster runs in one region.

1. Evaluate the single-schema, row-level-security design against the stated requirements. What gaps exist?

Read the worked answer

The design addresses confidentiality partially and the other requirements poorly.

Confidentiality: row-level security can work, but it concentrates risk in one control. A single misconfigured policy, a view that bypasses RLS, or a query path that runs as a privileged role exposes all 14 units at once. The blast radius of one mistake is the entire platform. It also makes least-privilege auditing harder, because every unit's data sits behind the same object.

Noisy neighbor: the proposal has no per-tenant resource isolation, so the 40,000-query-per-day unit and the 2-query-per-day unit compete for the same compute. A runaway query from the heavy unit will degrade the light units, directly violating the requirement. Row-level security does nothing for this; you need workload isolation such as separate compute pools, query queues with per-tenant concurrency limits, or resource groups with CPU and memory caps.

Data residency: a single-region cluster cannot satisfy the two units with regional obligations. Those units need either a separate deployment in their required region or a documented, approved exception. A shared cluster in one region is a compliance finding waiting to happen.

A stronger design keeps a shared control plane but isolates data by schema or database per unit, applies per-tenant compute quotas, and splits the two regulated units into regional deployments. The cost saving from one deployment is real but should not be pursued by collapsing every boundary at once.

2. Propose a migration path that preserves the cost goal while closing the isolation gaps.

Read the worked answer

Phase the change so the platform does not lose the shared-cost benefit while boundaries are established.

  1. Inventory and classify. Confirm which units have hard residency requirements and which have soft preferences. Identify the top consumers by query volume and peak concurrency. This determines where isolation spend is justified.

  2. Isolate the regulated units first. Stand up regional deployments for the two units with obligations. This is non-negotiable and removes the largest compliance risk immediately.

  3. Introduce compute isolation before data isolation. Add per-tenant resource groups or queues with concurrency and memory caps. This is usually cheaper than splitting storage and directly fixes the noisy-neighbor requirement. Validate with a load test that one tenant's runaway query cannot push another's latency past an agreed threshold.

  4. Move high-volume and high-sensitivity units to dedicated schemas or databases on the shared cluster. Keep the long tail of low-volume units on the shared schema with RLS, since their risk and load are small. This preserves most of the cost saving.

  5. Add defense in depth for the shared tier: separate roles per unit, no shared superuser for application queries, query auditing, and automated tests that attempt cross-tenant reads on every deploy.

The result is a tiered model: dedicated regional deployments for regulated units, dedicated schemas for heavy or sensitive units, shared schema with RLS for the long tail, and per-tenant quotas everywhere. Cost stays close to the single-deployment target while each stated requirement has a named control.