Data Platform Tenancy
How a shared data platform separates domains and customers across storage, compute, catalogue and access control.
Tenancy in a data platform is harder than in an application platform because the whole point of the platform is that data is joined across boundaries. Perfect isolation would defeat it; no isolation makes it ungovernable.
The separable dimensions are worth treating independently. Storage isolation by account, bucket or database defines the strongest boundary and the one auditors understand. Compute isolation prevents noisy neighbours and makes cost attributable. Catalogue separation determines who can even see that a dataset exists, which matters for sensitive domains where the existence of a table is itself informative. Access control determines who reads what, ideally at row and column granularity rather than table granularity.
For a platform serving external customers, the additional question is whether tenant data shares tables with a discriminator column or occupies separate objects entirely. The shared-table model is efficient and one missing predicate away from a cross-tenant data breach, which argues for enforcing the separation in the platform layer — row-level security policies or per-tenant views — rather than trusting every query to include the filter.
The rule that holds generally: isolate by the strongest mechanism the regulatory and commercial context requires, and no stronger, because every boundary added is a join that becomes a project.