The million dollar query is real and it is almost always the same shape: a full scan of a large, unpartitioned table, often with select star, run on a schedule so it repeats every hour or every day. Because BigQuery on demand bills by bytes scanned, not rows returned, that one pattern reads the entire table every single run and the cost compounds with the schedule until it dominates the bill. Killing it is a two step move. First find it by ranking jobs by bytes billed in INFORMATION_SCHEMA or the audit logs. Then cut what it reads: partition the table on the column it filters by so scans skip irrelevant data, cluster on common filters, select only the needed columns, and cap maximum bytes billed so no single query can run away again.
One query can be a bigger problem than your entire compute fleet. Here is how to find it and how the layout fixes it.
Why does one query cost so much?
On demand BigQuery pricing has one input that matters: the bytes a query scans. It does not charge for compute time, for how clever the query is, or for the size of the result, only for how much data the engine had to read to produce it. A full scan of a large table reads all of it, and select star forces every column to be read even if the query uses three. Now put that query on a schedule. A full table scan that runs once is a moderate cost; the same scan run hourly runs up that cost twenty four times a day, every day. The million dollar query is rarely a one off, it is a cheap looking query multiplied by a relentless schedule against a table that grows.
How do you find it?
BigQuery records every job, and the bytes billed are in the metadata, so you can rank spend without guessing. Query the INFORMATION_SCHEMA jobs views or the audit logs to total bytes billed per query, per user, and per scheduled job over a representative window, and sort descending. The top of that list is, on demand, the top of your bill. You will usually find a small number of scheduled queries and dashboards responsible for a large share of all bytes scanned. That concentration is good news: fixing a handful of queries removes most of the cost, and you do not need to touch the rest.
What cuts the data it reads?
Once you have found the offenders, the levers are about reading less. The table shows what each one does against a baseline of a full table scan with select star.
| Technique | What it does | Effect on bytes scanned |
|---|---|---|
| Partition the table | Splits the table by a column queries filter on, usually date, so scans read only matching partitions | Large reduction on filtered queries that touch a narrow range |
| Cluster the table | Sorts data by common filter columns so the engine prunes blocks within a partition | Further cuts bytes read on filtered and aggregated queries |
| Select only needed columns | Avoids select star so only referenced columns are read | Reads a fraction of the row width in columnar storage |
| Materialize repeated results | Precomputes a summary the dashboard scans instead of the raw table | Replaces repeated full scans with a small scan |
| Maximum bytes billed and reservations | Caps the data a query may scan and isolates workloads | Stops any single query running away again |
Stacked together, partitioning and clustering plus column selection routinely take a runaway query from scanning a whole table to scanning a sliver, and the cost falls in direct proportion. Setting a maximum bytes billed limit turns the fix into a guardrail so the problem cannot silently return.
A worked example of a killed query
A Fortune 500 retailer found, by ranking jobs in INFORMATION_SCHEMA, that a single hourly dashboard refresh was scanning an entire unpartitioned events table with select star and accounted for the majority of its BigQuery spend. We partitioned the table by event date, clustered it on the two columns the dashboard filtered on, rewrote the query to select only the needed columns, and set a maximum bytes billed limit as a guardrail. Bytes scanned by that job fell to a small fraction of the original and the dashboard ran faster, and the change was part of the work that left the GCP estate materially lighter. Figures are verified against billing data and anonymized.
Rank your BigQuery jobs by bytes billed for the last month. If a handful of scheduled queries or dashboards account for most of it and they scan unpartitioned tables, you have million dollar queries hiding in plain sight, and partitioning will remove most of the cost.
Where this fits in the GCP estate
Killing the runaway query is one part of BigQuery cost discipline. Decide the pricing model in on demand versus capacity pricing in BigQuery and govern repeating jobs in scheduled queries and cost discipline. The full picture lives in the GCP cost optimization guide, which links across to the cross cloud cost optimization guide.
Frequently asked questions
What makes a BigQuery query so expensive?
How do you find the most expensive BigQuery queries?
How do you stop a runaway BigQuery query?
Get the buyer side BigQuery cost playbook
We find the queries scanning the most data and cut what they read with partitioning, clustering, and guardrails, so one query stops dominating your bill. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.