Every quarter, a finance team somewhere flags warehouse spend as a line item that has grown faster than revenue. The reflexive response is to ask the data team for “an optimization plan,” which usually produces a deck of generic recommendations — right-size warehouses, add clustering, review reservation commitments. None of it moves the bill. Three months later the line item is bigger.
The reason this happens is straightforward: warehouse cost is dominated by a small number of query patterns that are orders of magnitude more expensive than the rest. Average tuning does not touch them. The work is not to optimize broadly; it is to find the specific queries that are eating the budget and fix them with prejudice.
The shape of warehouse overspend
In every cost audit we have run, the same distribution shows up. Roughly 5% of queries consume 80% of compute. Inside that 5%, three patterns dominate.
Full-table scans behind dashboards. A dashboard tile gets built against a fact table the size of the company’s entire transactional history. The author writes a WHERE clause on a non-partitioned column, or — more commonly — relies on a BI tool that strips predicates during render. Every refresh scans the full table. Every executive opening that dashboard at 8 a.m. fans out the scan to a fresh warehouse spin-up. A single tile can generate four-figure daily costs without anyone noticing, because the cost is amortized across hundreds of users and dozens of warehouses.
Runaway iterative jobs. A pipeline written by an analyst three years ago loops over a list of customer IDs and issues one query per ID. It worked when the customer list was 800 rows. The customer list is now 80,000 rows. The job runs nightly. Each iteration spins up a session, executes a small query, and tears down — and the per-query overhead is now larger than the actual work. These jobs are nearly impossible to find by reading code, because the code looks fine; you find them by sorting query history by call count and asking why a single procedure issued forty thousand identical-looking queries last Tuesday.
Mis-sized warehouses. A team provisions an X-Large warehouse for a workload that needs Medium, then never revisits the decision. The workload runs in a third of the wall time, but the per-second cost is eight times higher and concurrency credits get burned holding the warehouse warm. The reverse is just as common: a Medium warehouse handles a workload that needs Large, queries spill to remote disk, and the wall-time cost dwarfs the rate savings. Right-sizing is not a one-time exercise; it has to track the workload as the workload changes.
These three patterns are not exotic. They are the boring, structural kind of waste that every warehouse generates and that no generic optimization framework finds, because the framework operates at the wrong altitude.
The six-week plan
Optimization that actually moves the bill is a project with a beginning, a middle, and an end. Six weeks is the right size — long enough to do the work, short enough that attention does not drift.
Week 1 — Instrument and rank. Pull query history for the trailing 90 days. Group by query fingerprint (or query_hash / statement_id, depending on the platform). Rank by total credit consumption, not query count. Publish the top 50. This list is the project. Everything else is a distraction.
Week 2 — Triage the top 20. For each of the top 20 fingerprints, identify the owning team, the business surface it powers (dashboard, pipeline, ad-hoc), and the failure mode. Most will fall into one of the three patterns above. Categorize them. Resist the urge to fix anything yet.
Week 3 — Fix the dashboard tier. Dashboard scans are the highest-leverage fix because the cost recurs every time a user opens a tab. Add partition predicates to the underlying queries. Materialize aggregates where the dashboard is asking the same question repeatedly. Move stale dashboards behind a “request to refresh” button. Expect to retire 10–20% of the dashboard estate in passing — the queries powering them turn out to be unused once you look.
Week 4 — Fix the iterative jobs. Rewrite per-row procedures as set-based SQL. Replace cursor loops with MERGE statements. Move ID-list iteration into staging tables and a single join. The first job you fix will collapse from forty minutes to forty seconds, and the team that wrote it will spend the rest of the week looking at every other procedure they own.
Week 5 — Right-size the warehouses. Now that the workload shape has changed, re-evaluate warehouse sizing against the new baseline. Drop sizes where queue times allow. Consolidate warehouses where workloads are compatible. Write down the sizing rules so the next person who provisions a warehouse has a defensible default.
Week 6 — Lock it in. Stand up cost monitoring with budget thresholds at the workload level, not the account level. Establish a weekly review cadence — 30 minutes, the data lead and one finance partner, looking at the top 10 fingerprints. Document the patterns you found so the next dashboard built against the fact table fails review for the right reason.
What this gets you
Done with discipline, six weeks of focused work removes 40–60% of warehouse spend on a typical mid-sized data platform. The savings are durable as long as the weekly review survives — which is the real deliverable of the project, not the percentage. Cost optimization is a habit, not an event. The six weeks exist to install the habit; the percentage is what proves the habit was worth installing.
The teams that fail at this fail in a predictable way: they treat cost optimization as a cross-cutting initiative everyone owes a little time to, rather than a project with an owner and a deadline. The work is not technically hard. The discipline of staring at the top 20 query fingerprints until each one is either fixed or explained — that is the entire job.