How this session works
In a4 you learned the pricing shapes: per TB scanned, per compute-second, per credit. Today we follow the money after the contract is signed. No tuning syntax - the builder track's session b8 is the hands-on twin of this page. Your job is different: understand the physics well enough that "the warehouse bill doubled" becomes a conversation you can lead, with questions that have right answers.
Why warehouse bills explode 8 min live
Cloud warehouses charge for work: per TB scanned (BigQuery's shape) or per second of compute (Snowflake's shape). That is fair - and it means every wasteful query is a small invoice. Bills do not explode because storage got expensive. They explode because compute quietly serves habits instead of decisions: whole-table scans for three columns, dashboards refreshing for empty rooms, one runaway join.
LiveThe meter runs on scans, not on answers4 min▶
The mental model that unlocks everything: a warehouse charges you for the data it touches, not the rows it returns. A query that returns one number can scan two terabytes to compute it. That is why identical-looking dashboards can differ 100x in cost - the difference is invisible on the screen and enormous on the meter.
- Per-scan engines (BigQuery shape): the invoice literally lists bytes scanned. SELECT * on a 60-column table bills all 60 columns even if the chart uses 3.
- Per-compute engines (Snowflake shape): you pay for the seconds a warehouse runs. Wasteful scans keep it running longer - same waste, different meter.
- Why nobody notices: each incident is small. Fifty small habits, compounding daily across every dashboard, are how a bill doubles in two quarters with no single culprit.
The dashboard that cost more than the analyst. A CFO asked why the analytics bill had tripled. The audit found one executive dashboard set to refresh every five minutes, around the clock, scanning the full order history each time. It was viewed roughly twice a day. The refresh interval was changed to hourly during business hours - a one-line setting - and the bill dropped by a third. Nobody had done anything wrong; nobody had ever looked.
Self-studyWhy "add an index" is not the answer here2 min read▶
If you learned databases in the app world, your instinct says "slow query, add an index". Warehouses mostly do not work that way. Indexes accelerate finding a few rows; analytics scans millions. Columnar engines got rid of classic indexes and replaced them with a different toolkit - reading fewer columns, skipping irrelevant slices of data, remembering answers. That toolkit is Part 2, and it is the vocabulary your data lead already uses: pruning, partitioning, clustering, materialized views, caching.
Self-studyA leader's glossary for the invoice3 min read▶
Five words that appear on real warehouse invoices, translated once so the bill stops being a foreign document:
- Bytes scanned / TB processed: how much data your queries touched. The core meter on scan-priced engines - this is the number the four levers shrink.
- Compute hours / credits / DBUs: how long engines ran, in the vendor's local currency. Same physics, different unit: waste keeps the clock running.
- Slots / warehouse size: how much horsepower was reserved. Reserved and unused still bills - that is lever 4's territory.
- Storage (active vs long-term): what sits on disk. Cheap per GB, but old copies and abandoned tables add up quietly - and clutter has a governance cost beyond the invoice.
- Egress / data transfer: data leaving the platform or crossing regions. Small on most months, decisive when you migrate - which is why a4 put it in the contract questions.
The four levers, in exec terms 9 min live
Every warehouse engine - Snowflake, BigQuery, Redshift, Databricks, even DuckDB - offers the same four levers under different brand names. You do not pull them yourself. You fund them, ask about them, and recognize when one is being ignored.
LiveWhat each lever sounds like in a status update4 min▶
You will never pull these levers, but you will hear them. Translation table:
- "We cleaned up the worst queries" = lever 1. Analysts named columns instead of SELECT *, trimmed wide joins. Cost: a few days of attention. Often the single biggest win.
- "We partitioned the big tables by date" = lever 2. The 30-day dashboard now reads 30 days, not five years. One-time engineering work that pays rent forever.
- "We materialized the daily rollups" = lever 3. The revenue dashboard reads a small pre-computed table instead of re-scanning raw orders 500 times a day. Builder session b7 builds exactly this for Daybreak.
- "We set auto-suspend to 60 seconds" = lever 4. Compute now sleeps between queries instead of idling on the clock. In credit-based engines this is often the fastest fix on the list.
Self-studyPerformance and cost are the same lever2 min read▶
Nothing in Part 2 was a cost trick. Reading fewer columns, skipping partitions, serving cached rollups - each one also makes the dashboard load faster. In a warehouse, waste is measured twice: once in seconds (the analyst waits) and once in dollars (the meter runs). This is why "make it cheaper" and "make it faster" are one project, not a trade-off - a genuinely unusual property. Spend it in the boardroom: the cost-review project is also the user-experience project.
Self-studyThe same levers, in each vendor's accent2 min read▶
When your team names a feature, map it back to the lever - the brand names change, the four moves never do:
| Lever | Snowflake accent | BigQuery accent |
|---|---|---|
| 1 · Ask for less | Column pruning over micropartitions | Fewer columns = fewer bytes billed |
| 2 · Skip data | Clustering keys, partition pruning | Partitioned + clustered tables |
| 3 · Compute once | Materialized views, result cache | Materialized views, BI Engine cache |
| 4 · Right-size | Auto-suspend, warehouse sizing | Slot commitments sized to need |
Redshift, Databricks, and even DuckDB tell the same story in their own vocabulary. If a proposed fix does not map to one of the four rows, ask which lever it is pulling.
Five questions for your data lead 7 min live
You do not manage warehouse cost by reading queries. You manage it by asking five questions once a month and listening for whether the answers exist. Teams that can answer them have the amber band under control; teams that cannot are about to surprise you.
LiveThe five questions, and what good answers sound like5 min▶
- "What are our ten costliest queries this month?" Good: a list exists, with owners, and the top one is being fixed. Bad: "we'd have to look into that" - every engine ships this report; not reading it is a choice.
- "Is scan-per-dashboard trending up or down?" Good: down or flat while usage grows - the levers are working. Bad: nobody tracks per-dashboard cost, so growth and waste are indistinguishable.
- "What is our storage vs compute split?" Good: storage is a sliver and they know the ratio. Bad: a big storage bill usually means old copies and abandoned tables nobody dares delete - cheap to fix, embarrassing to admit.
- "What share of dashboard reads hit a cache or materialized view?" Good: the top dashboards read pre-computed rollups, raw scans are the exception. Bad: every glance at the revenue chart re-scans all of history.
- "Who reviews new dashboards before they ship?" Good: a named person checks scan cost and refresh schedule - a five-minute gate. Bad: anyone can point anything at the biggest table on a five-minute refresh, and eventually someone does.
The boardroom moment. A CEO opened a quarterly review with one slide: warehouse spend up 80%, revenue up 12%. The data lead had the answer ready: spend per active dashboard was down 30% - the growth was 40 new dashboards shipped for two new business lines, each reviewed and each cached. The conversation took ninety seconds and ended in a bigger budget. That is what the five questions buy: not a smaller bill, a defensible one.
Self-studyWhen the bill SHOULD go up2 min read▶
A word of balance before you take the five questions home. The cheapest warehouse is an unused one. If the bill is rising because more teams make more decisions from data - new marts, new markets, a model in production - that is the system working. The target is not a small number; it is no amber band: every scanned terabyte serving someone. Judge the bill the way you judge a sales-travel budget: not by size, but by what came back.
Take this back to your desk ◐ 20 min
- Get last month's warehouse bill and find the storage vs compute split. Predict it before you look - the gap between your guess and reality is this session's lesson landing.
- Ask your data lead question 1 ("ten costliest queries?") this week. You are testing whether the list exists, not whether the queries are pretty.
- Find one dashboard on an aggressive auto-refresh and ask who looks at it, and when. If the honest answer is "twice a day", you have found your first amber-band win.
- Ask the doubling question: "if our data doubled, would the bill double?" Note which levers come up in the answer - and which never get mentioned.
- Put a ten-minute "warehouse cost" slot in next month's ops review, using the five questions. The ritual matters more than the first month's answers.
Official sources covered
The leader track distills the cost-and-performance material of the major curricula to executive altitude - the physics and the questions, without the tuning labs. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your warehouse bill doubled in six months. Statistically, the most likely culprit is...
Storage is the sliver; compute is the bulk, and waste hides inside it. Bills explode from fifty small habits compounding daily, almost never from one dramatic cause.
2 · "We materialized the daily revenue rollup" means...
Lever 3: compute once, read many. The revenue chart now reads a small pre-built table - faster for users and cheaper on the meter, at the same time.
3 · The best sign that warehouse cost is under control is...
A falling bill might just mean falling usage. Control means visibility plus a gate: the amber band is measured, owned, and shrinking - even while the total grows with the business.