Nobody sets out to waste money on Snowflake. It happens quietly.
During setup, someone picks Medium because it seems reasonable. Or Large, because a
dashboard was slow that one time. The warehouse works. Queries finish. Nobody touches it
again.
Six months later, you’re burning double the credits you need to. Not because anything broke.
Because nobody went back to check.
We see this in almost every Snowflake environment we touch at DSC. Warehouse oversizing is
the single most common source of avoidable spend, and it hides in plain sight.
How it happens
When a team spins up a new warehouse, the priority is getting things working. Fair enough. But
“working” and “right-sized” are two very different things.
Here’s the pattern we see repeatedly:
A warehouse gets created at Medium or Large during implementation. Dashboards load.
Pipelines run. Everyone moves on to the next problem. The warehouse stays at that size
forever.
Nobody downsizes because nobody wants to be the person who broke the BI layer. And without
data on actual utilization, it feels like a gamble. So the default sticks.
The problem is that Snowflake pricing scales linearly with warehouse size. Medium to Large
doubles your credit burn. Small to Large quadruples it. If the workload doesn’t need that
compute, the difference is pure waste.
What it looks like in practice
This isn’t dramatic. It’s boring. That’s why it persists.
Queries finishing in 2 seconds on a Large that would finish in 3 seconds on a Small. A BI
refresh running hourly on Medium with one concurrent user. A transformation job that spikes for
30 seconds but holds a Large warehouse active for 10 minutes because auto-suspend is set to
the default 5 minutes.
None of these trigger alerts. All of them cost you money every single day.
Take one warehouse running 8 hours a day, 5 days a week, sized one step too large. That’s
roughly 160 hours per month of excess compute. At Snowflake’s standard pricing, you’re looking
at hundreds to thousands of dollars in waste from a single warehouse. Most environments have
5 to 15 of them.
Why nobody catches it
It’s not a visibility problem. Snowflake gives you the data. It’s an ownership problem.
Engineering manages the pipelines. Analytics owns the dashboards. Finance sees the invoice.
Nobody owns warehouse efficiency. There’s no recurring review. No baseline for what
“right-sized” means for a given workload.
And when spend comes up in a planning conversation, the response is usually to look at query
optimization or storage cleanup. The warehouse sizes themselves rarely get questioned
because they’ve always been that way.
The fix is simpler than you think
You don’t need to rearchitect anything. You need three things:
Utilization data per warehouse. Look at AVG_RUNNING and AVG_QUEUED_LOAD from
WAREHOUSE_LOAD_HISTORY. If average running queries are consistently below 1.0 over 30
days, the warehouse is oversized.
A benchmark test. Pick your top 3 warehouses by spend. Drop each one size. Monitor for a
week. If queries still finish within acceptable thresholds and nothing queues, keep the smaller
size.
An auto-suspend check. The default is 5 minutes. For most ad-hoc and BI warehouses, 60
seconds is fine. That alone can cut idle credit burn by 20-30%.
This isn’t a one-time exercise. Workloads change. Dashboards stabilize. Models get more
efficient. What was the right size 6 months ago probably isn’t today.
What we built for this
DSC Optimizer connects to your Snowflake account and surfaces exactly this: which
warehouses are oversized, what they should be, and how much you’d save by changing them.
No percentage-of-spend pricing. A flat $199/month.
If you’re spending $50K+ a year on Snowflake and haven’t reviewed your warehouse sizes
recently, it’s worth a look
Check out DSC Optimizer →
