Sizing a Snowflake Warehouse Shouldn’t Be a One-Time Guess

Here’s how warehouse sizing usually actually happens. Someone spins up a new warehouse and runs a few queries. They notice it’s a little slow during the busiest hour of the week, so they bump it up a size to be safe. Maybe two sizes, just in case. That size then becomes “the size” for good. Nobody worked out what the warehouse actually needs most of the time. It was just good enough for the worst hour, once. Often it becomes official enough to end up in the name itself – etl_warehouse_l, analytics_xl. That quietly locks the decision in even further, since changing the size now means the name stops matching reality too. Nobody wrote the original decision down anywhere, and nobody’s really the owner of revisiting it later. From then on, it’s just what the warehouse runs as, and what everyone calls it.

This article is part of our guide to Snowflake warehouse optimization. For what each size costs, see Snowflake warehouse sizes and credits per hour.

The problem is that the worst hour isn’t most hours. A warehouse sized for Monday morning’s load runs at that size all day Tuesday, all weekend, every quiet night in between. Whenever it is running, it pays for capacity that’s only earning its keep for a sliver of the week. The rest of the time, it has far more capacity than the work needs. Yet the price tag assumes it’s always busy. Multiply that by every warehouse your team has ever sized this way – and most teams have more than one. Then “a bit oversized, just in case” turns into a real, ongoing cost that nobody consciously chose to pay. Nobody makes this mistake on purpose. It’s just what happens when sizing is a one-time guess instead of something that keeps up with reality.

And that’s before the generation question even comes up

On top of picking a size, there’s also a generation to pick. Most teams have never had a clean way to know which one actually fits a given workload. Gen2 warehouses often perform better for the same size on the right kind of workload. But you can’t eyeball “the right kind of workload” from a dashboard. And most people don’t have time to go test it properly. So teams either stick with whatever they started on, or guess. Once they make a guess, they rarely revisit it. Revisiting it means setting aside real time to test, compare, and second-guess a decision that already feels settled.

Why this almost never fixes itself

In theory, someone could go back through every warehouse every few months. They could check the actual usage pattern and re-tune the size and generation by hand. In practice, that almost never happens. Not because it isn’t worth doing, but because it competes with everything else on a data team’s plate. And a warehouse that’s “working fine” never feels urgent enough to interrupt that for. So the guess from day one keeps running quietly for as long as the warehouse exists – name and all.

SmartPulse takes the guessing out of sizing

SmartPulse looks at how your team actually uses a warehouse, hour by hour, instead of trusting a size someone picked once. It then builds a schedule around that: bigger when the load calls for it, smaller the rest of the time. The schedule applies once you approve it. It keeps re-checking the real pattern of usage and surfaces updates for you to accept as that pattern changes. It doesn’t freeze in place the moment someone decided “this seems fine” and moved on. SmartPulse makes the size-and-generation call the way it should have worked from the start. It bases the call on what’s actually happening on the warehouse right now, not on a guess nobody reconsidered. SmartPulse schedules warehouses that have a predictable usage pattern. If a warehouse’s usage is too irregular to forecast, it doesn’t get an automatic schedule. That way you always know which warehouses SmartPulse covers.

You choose how it optimizes

SmartPulse runs in one of two modes, so the tradeoff is yours to set, not assumed for you. Cost mode leans toward the leanest size that still handles the work. Performance mode leans the other way, favoring headroom so queries stay fast even as load shifts. You can also set an SLO, so the schedule respects the performance bar you actually need, not a generic default. Either way, SmartPulse hands you a ready-to-review plan, listing the size and generation changes, before anything takes effect. Then you make the call. Accept the schedule as it stands, or lean it further toward savings or performance, depending on what that warehouse needs. Once it is running, Seemore reports savings warehouse by warehouse, so you can see the effect on your bill.

It doesn’t ignore sudden spikes

Alongside the hourly schedule, SmartPulse includes Burst Protector. It watches for queueing that the scheduled size can’t absorb. It then scales the warehouse up within seconds and back down once the spike passes. Burst Protector also has its own modes, so you decide how aggressively it steps in when something unusual happens. That way a warehouse doesn’t stay undersized the moment traffic breaks from the normal pattern.

You can see exactly what it’s doing

None of this runs as a black box. You approve the schedule before it takes effect. If you want to override something yourself, you can also set static time slots manually for any warehouse. You can see exactly who activated SmartPulse on a given warehouse. You can also follow everything it does through Seemore’s event log and real-time monitoring. That leaves a clear, visible record of what changed and when.

And when you know something’s coming, you can step in

Sometimes you know in advance – or notice on the spot – that a warehouse must handle something unusual. Then switch on Live Tuning and set the warehouse’s configuration yourself for 5 minutes to 24 hours. SmartPulse’s schedule pauses for that time and picks up again from the current hour slot when Live Tuning ends.