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: a warehouse polled every couple of minutes against a 60-second timeout suspends and resumes constantly, and every resume bills at least 60 seconds regardless of how brief the query was. Lowering auto-suspend to fix the first problem can make the second one worse for a chatty workload.

The fix isn't a single "right" timeout. It's matching the timeout to the query pattern: infrequent, bursty queries want a short timeout; steady, frequent polling wants either a longer one or a switch away from polling altogether.

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's a fair trade when a workload is genuinely compute-bound and finishes proportionally faster on the bigger warehouse. It's a bad one when the warehouse was sized for a peak that rarely happens, or for a query that's bottlenecked on something a bigger warehouse can't fix, like a missing partition or waiting on 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. A single metadata-heavy workload, like a burst of DESCRIBE or SHOW commands, or heavy result-set caching misses, can push a normally-quiet account over the threshold for a day, and the whole excess bills at once rather than 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 a lot of daily churn, like one truncated and reloaded nightly, can carry meaningfully more retained-version storage than its live size suggests, for no reason visible in a normal row count.

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. That's a straight cost with nothing to show for it whenever the code downstream only reads a handful of those columns, which is most of the time.

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, but it's also the cap on how much a single bad query, or a runaway scheduled job, can spend before it's throttled. A max set far above typical usage "just in case" is a real, uncapped-in-practice exposure, 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, and modifying it, even a single row update or a metadata change, resets that counter to zero. A table that's appended to nightly, however small the append, never reaches the discount no matter how old most of its data actually is. Partitioning old data into a separate, untouched table is what actually earns the discount.