Size a Snowflake warehouse around the workload, not a guess.

Start with a workload description

“The warehouse is slow” is not yet a diagnosis. A single expensive transformation, many concurrent dashboard queries and an ingestion burst have different resource shapes. Write down the workload, its expected completion time, how many jobs or users run concurrently and what delay is acceptable.

Consider a small reporting team. A scheduled transformation must finish before morning, while dashboard readers arrive together after a meeting. Those two workloads can compete even when either behaves reasonably in isolation. Separate their timings in your measurements before deciding whether a larger warehouse is the right intervention.

Ask three questions separately

First, how much work does an individual query perform? Look at the query plan and actual data processed. Avoid drawing conclusions from the SQL text's length: a short query can still scan or join a large amount of data. Second, how does the workload behave under concurrency? A query that is acceptable alone can miss its target when many peers compete. Third, what cost and operational limits apply to the chosen configuration?

Snowflake virtual warehouses provide compute, and multi-cluster configurations address concurrency through additional clusters under their documented policies. These are related controls, not interchangeable promises that every query will run faster. Account edition, workload and configuration matter; use current Snowflake documentation for the supported behavior.

Run a controlled comparison

Record a representative query or job set, dataset version, concurrency, warehouse configuration and timing window. Change one factor at a time. Compare execution time, queueing, failures and the actual usage reported by the platform. Keep enough repeated observations to see whether a result is consistent rather than a one-off.

Do not compare an idle morning run to a heavily loaded afternoon run and attribute the entire difference to warehouse size. Similarly, cache effects and changing data volume can make before/after comparisons misleading. Document those conditions so another engineer can reproduce the reasoning.

Use a teaching model for reasoning, not billing

Suppose an educational model assigns a warehouse cluster 400 work items per second. A 600-item/s input exceeds that modeled capacity. Two identical modeled clusters provide 800 items/s under a linear-capacity assumption. This is useful for exploring admission and backlog, but it is not a statement that a real Snowflake query has an equivalent fixed request rate.

The model does not execute the query plan, emulate storage behavior or reproduce warehouse startup and billing details. Relative resource units in CodeYourself are not Snowflake credits or currency. Use actual vendor usage and current pricing for a real cost estimate.

Finish with an operational decision

Choose the smallest change that addresses the measured problem. That might be a query improvement, workload scheduling, separation of competing workloads or an appropriate scaling configuration. Define how you will know it worked and what triggers rollback. Set a review date so a temporary performance change does not become an unexplained permanent cost.

The practical skill is not memorizing a warehouse size. It is connecting a specific workload to evidence, a controlled change and an observable result.