Snowflake Cost Control: Size Your Warehouses Before the Bill Does It for You

The first Snowflake invoice that makes a manager call a meeting is rarely caused by a huge query. It is usually a warehouse somebody resized to Large for a demo, never resized back, and left running over a long weekend while nobody looked at a dashboard.

Snowflake charges for compute in credits, and compute lives in virtual warehouses. Storage is a separate and usually smaller line. So cost control is mostly a question of how your warehouses are sized, how long they stay awake, and who is allowed to start them.

How a Warehouse Spends Credits

A warehouse costs credits only while it is running. Billing is per second, with a 60-second minimum each time it resumes. Size sets the rate: every step up, from X-Small to Small to Medium and on, doubles the credits burned per hour.

That doubling is the part worth memorizing. A Large warehouse running for one hour costs as much as sixteen X-Small hours. Going up a size is a decision about money, and it only pays off if the query finishes in roughly half the time. Often it does for big scans and joins. For a small dashboard query that already returns in two seconds, it just doubles the cost for the same answer.

Five Settings That Do Most of the Work

Before any clever tuning, get the boring settings right. Most accounts that overspend have at least three of these wrong.

Auto-suspend deserves the most attention. An idle warehouse still bills until it suspends, so a ten-minute timeout on a warehouse that serves one query an hour means paying for nine minutes of nothing each time. Dropping it to 60 seconds is usually safe because resume takes a second or two.

There is one honest trade-off. A suspended warehouse loses its local data cache, so the next query reads from storage again and may feel slower. For a BI warehouse hit constantly all day, a slightly longer timeout can be cheaper in practice than constant cold starts. For a nightly load job, suspend immediately.

Splitting warehouses by workload matters for a second reason: you can see who spent what. When the loading team, the analysts and the data scientists all share one warehouse, the credit graph tells you nothing. Give each its own and the graph becomes an answer.

Find What Is Burning Credits

You do not need a third-party tool to start. Snowflake exposes usage through views in the SNOWFLAKE.ACCOUNT_USAGE schema. Two are worth bookmarking.

WAREHOUSE_METERING_HISTORY shows credits consumed per warehouse per hour. Group it by day and warehouse, and the expensive one is obvious within a minute. Then open QUERY_HISTORY and filter to that warehouse and period. Sort by total elapsed time, and look at the queries that ran longest or scanned the most data. A single report that scans a whole table every fifteen minutes will stand out immediately.

These views are populated with a delay, so a query you ran five minutes ago may not appear yet. Check again later before concluding something is missing.

Cheap Wins Inside the Queries

Once the warehouse settings are sane, look at what runs on them.

None of this requires changing infrastructure. It is a code review, and it is usually the cheapest hour of work in the whole project.

Put a Ceiling on It

A resource monitor sets a credit quota for an account or for specific warehouses over a period. You can have it send a notification at, say, 75 percent and suspend the warehouse at 100 percent. Create one per warehouse for non-production work first. A runaway test job hitting a hard cap is an annoyance. The same job with no cap is an invoice.

Keep one rule of thumb for the whole account: nothing should be able to spend unlimited credits without a person having chosen that.

Next Step

Warehouse behaviour, query optimization and cost management are part of the performance module in the Snowflake Training course at SkyTrainings, which runs 2.5 months and includes real-world projects.