Virtual Warehouse Sizing
16 min
Snowflake's core architectural idea: STORAGE (your data) and COMPUTE (the "virtual warehouses" that query it) are completely separate. Multiple warehouses — sized independently, billed independently — can query the exact same data at the same time with zero contention. Warehouse sizes follow a doubling "T-shirt size" scale: each size up doubles both the compute power and the credits-per-hour cost.
def warehouse_cost(size, hours, credit_price=3.0):
size_credits = {"X-Small": 1, "Small": 2, "Medium": 4, "Large": 8, "X-Large": 16}
credits = size_credits[size] * hours
return round(credits * credit_price, 2)
Because storage and compute are separate, a team can freely resize (or entirely shut down) their warehouse without touching the data at all -- spin up a Large warehouse for an hour to blast through a big backfill, then drop back to X-Small for routine queries, paying only for compute actually used at each size.
Write `warehouse_cost(size, hours, credit_price=3.0)`: each T-shirt size doubles the credits-per-hour of the size below it — `X-Small`=1, `Small`=2, `Medium`=4, `Large`=8, `X-Large`=16. Return `size_credits * hours * credit_price`, rounded to 2 decimal places.
Snowflake separates STORAGE from COMPUTE — data sits in one place, but any number of independently-sized 'virtual warehouses' can query it. Why is that architectural split valuable?
You can compute virtual warehouse costs across Snowflake's T-shirt sizing scale, and understand why separating storage from compute lets multiple workloads run concurrently without contention.