What is your data warehouse actually costing you?

Auto-suspend has a cost in both directions, not just one

A long auto-suspend timeout bills idle compute while a warehouse waits to suspend. A short one does the opposite. Say a query polls a warehouse every couple of minutes, with a 60-second timeout. The warehouse suspends and resumes constantly. Every resume bills at least 60 seconds, however brief the query was. Lowering auto-suspend to fix the first problem can worsen the second for a chatty workload.

No single timeout is right. Match the timeout to the query pattern. Infrequent, bursty queries need a short timeout. Steady, frequent polling needs a longer timeout, or no polling.

Each warehouse size step doubles the credit rate, not the value delivered

Going from Small to Medium to Large doubles the credits/hour rate at every step. That trade is fair when a workload is compute-bound and finishes proportionally faster on the bigger warehouse. It is a bad trade when the warehouse fits a peak that rarely happens. It is also bad when the query waits on something a bigger warehouse cannot fix, such as a missing partition or a slow upstream source.

Cloud services credits are free, right up until they're not

Cloud services usage only bills once it exceeds 10% of that day's warehouse compute credits. Under that line, it's invisible on the bill. One metadata-heavy workload can push a quiet account over the threshold for a day. Examples are a burst of DESCRIBE or SHOW commands, or many result-cache misses. The whole excess bills at once, not gradually.

Time Travel and Fail-safe both keep billing after data is gone

Deleting a row, dropping a table, or overwriting data doesn't free the storage it used. Time Travel keeps the prior version recoverable for the configured retention window, and once that ends, Fail-safe holds it for a further, non-configurable 7 days. A table with high daily churn, such as one truncated and reloaded nightly, can hold much more retained-version storage than its live size suggests. A normal row count does not show this.

SELECT * bills every column, even the ones the query throws away

BigQuery's columnar storage means a query that references three columns out of thirty only scans those three. SELECT * scans all thirty, every time, on every table it touches. This is a pure cost when the downstream code reads only a few of those columns. That is the usual case.

An Editions autoscale max isn't just a performance ceiling

Autoscaling slots above your committed baseline bill at the pay-as-you-go rate, per second, up to whatever max you configured. That ceiling protects query performance during a burst. It also caps how much one bad query or runaway scheduled job can spend before throttling. A max set far above typical usage "just in case" is a spend risk with no practical cap. It is not a free safety margin.

BigQuery's long-term storage discount resets the moment a table is touched

A table gets the 50%-off long-term storage rate only after 90 straight days with no modification. Any modification resets that counter to zero, even a single row update or a metadata change. A table with a nightly append never reaches the discount, however small the append is or however old most of its data is. Partition old data into a separate, untouched table to earn the discount.