Warehouse Concurrency Scaling
Adding compute clusters to absorb concurrent queries rather than queueing them, and the cost behaviour that turns a queue into a bill.
A fixed warehouse serves a limited number of concurrent queries; beyond that they queue, and users experience it as the platform being slow at nine in the morning. Concurrency scaling spins up additional clusters automatically to absorb the excess, converting a latency problem into a cost one.
That conversion is the thing to be deliberate about. It removes the queue and removes the signal — nobody complains, and the bill grows in a way that is hard to attribute after the fact unless per-cluster cost is tracked from the start.
The structural alternative is separation rather than elasticity: distinct compute for pipelines, for dashboards and for ad-hoc analysis, each sized for its own pattern. Pipelines are predictable and scheduled; dashboards are bursty and latency-sensitive; ad-hoc analysis is unbounded and occasionally catastrophic. Sharing one pool means the analyst's accidental cross join delays the morning refresh, which is the scenario worth designing away rather than scaling through.