Workload Isolation
Preventing one team's expensive query or backfill from degrading everyone else's analytics, by separating compute rather than sharing one pool.
Shared analytical compute has a characteristic failure: at 09:00 the executive dashboards are slow because a data scientist started a cartesian join, or an unbounded backfill has consumed the cluster. On a shared cluster this is a queueing problem with no clean answer, since the offending query is already running.
Separation of compute from storage is what made the fix straightforward. Different workloads get their own compute against the same tables — a small always-on cluster for dashboards with strict concurrency, an elastic one for transformation jobs, a separate one for exploratory work with aggressive auto-suspend, and an isolated one for any external-facing embedded analytics.
The trade is cost visibility versus utilisation: many small pools idle more than one large one, but they make spend attributable per workload, which is usually worth more than the utilisation.
The controls that go with it are the ones teams forget: per-pool query timeouts and scan limits, so an accidental full-table scan is stopped rather than billed; concurrency limits sized to the workload; and a default that suspends idle compute in minutes rather than hours, which is where a surprising share of analytics spend actually goes.