How do you configure a Snowflake multi-cluster warehouse, and what does SCALING_POLICY = 'ECONOMY' change?

## Scale up versus scale out Snowflake gives you two independent dials on a warehouse: - **`WAREHOUSE_SIZE`** — how much compute one cluster has. This is *scale up*, and it makes an individual query faster. - **`MIN_CLUSTER_COUNT` / `MAX_CLUSTER_COUNT`** — how many identical clusters the warehouse may run. This is *scale out*, and it lets more queries run at the same time. A multi-cluster warehouse is the second dial. All clusters are the same size; Snowflake routes each incoming query to a cluster. Multi-cluster warehouses require Enterprise Edition or higher. ## The two modes **Auto-scale mode** — `MIN_CLUSTER_COUNT` < `MAX_CLUSTER_COUNT`: ```sql CREATE WAREHOUSE bi_wh WAREHOUSE_SIZE = 'MEDIUM' MIN_CLUSTER_COUNT = 1 MAX_CLUSTER_COUNT = 5 SCALING_POLICY = 'STANDARD' AUTO_SUSPEND = 300; ``` The warehouse runs one Medium cluster normally; when concurrent demand exceeds what the running clusters can serve, Snowflake starts another, up to five. As load falls, extra clusters shut down. You pay per running cluster: five Medium clusters bill five times a Medium's rate for as long as all five are up. This is the shape almost every dashboard workload wants. **Maximized mode** — `MIN_CLUSTER_COUNT` = `MAX_CLUSTER_COUNT` > 1: every cluster starts when the warehouse resumes and runs until it suspends. There is no ramp-up delay and no scaling decision, which suits a predictable, sustained concurrency load (a fixed nightly reporting burst, a known peak window) where you would rather not wait for clusters to spin up. ## What SCALING_POLICY controls The policy tunes how eagerly clusters start and how reluctantly they stop. - **`STANDARD`** (default) — optimises for minimizing queueing. An additional cluster is started as soon as a query is queued, or the system detects one more query than the running clusters can take. Shutdown happens after a small number of consecutive one-minute checks showing the least-loaded cluster's work could be redistributed. - **`ECONOMY`** — optimises for saving credits. Snowflake starts an additional cluster only when it estimates there is enough queued load to keep that cluster busy for at least about six minutes, and it requires more consecutive checks before shutting one down. The consequence is direct: **during a burst, queries queue longer.** So the choice is a latency-versus-credits knob. Interactive dashboards where a human is waiting want `STANDARD`. A batch or internal-reporting warehouse where a couple of minutes of queueing is invisible is a legitimate `ECONOMY` candidate. ## Diagnosing which dial to turn The interview scenario is almost always "queries are slow in the morning — what do you do?" The discriminating evidence: - **Individual queries are fast, but wall-clock time from the user's perspective is long, and query history shows time spent queued.** That is a concurrency problem. Add clusters. - **A single query, run alone on an idle warehouse, is still slow — long scan time, or spilling to local and remote storage.** That is a per-query compute problem. Increase the size. Misdiagnosing costs real money in both directions: sizing up a queueing warehouse multiplies the credit rate without touching the queue, and adding clusters to a warehouse whose single query spills just gives you several equally slow clusters. `MAX_CONCURRENCY_LEVEL` (8 by default) is the related per-cluster property: it bounds how many statements one cluster runs at once before queueing. Raising it lets more queries share a cluster's resources — each getting less — and lowering it pushes work into the queue, or, on a multi-cluster warehouse, triggers another cluster sooner. It is a blunt instrument; most teams leave it alone and use cluster count instead. ## Cost control A multi-cluster warehouse's ceiling is `MAX_CLUSTER_COUNT` × the size's credit rate. That is the number to reason about when someone proposes `MAX_CLUSTER_COUNT = 10` on an X-Large: the worst hour is 160 credits. `MAX_CLUSTER_COUNT` is itself a budget lever — pick a number you are willing to pay for during a runaway burst, and back it with a resource monitor. ## Interview framing State the two dials and what each fixes, name the two modes and how the count settings select between them, then explain the scaling policy as a latency-versus-credits tradeoff with a concrete consequence (`ECONOMY` means users wait during bursts). Candidates who describe multi-cluster as "making queries faster" have missed the point entirely.