FFinitizerFree Tools
Free savings analysis

BigQuery Query Cost Analyzer

Paste a query and get the structural findings that drive its cost: columns read, partition pruning that works and pruning that only looks like it does, and the 10 MB-per-table floor. Add your schema or a dry-run figure and it prices the query exactly. No login, nothing uploaded.

Prices verified 4 Aug 2026

Your query

Your SQL is analysed in this browser tab. This page has no backend, so there is nothing to send it to — and nothing is written to the URL either.

Why there are three modes

BigQuery’s own cost estimate comes from a dry run, and a dry run needs credentials. This page deliberately has no backend and holds no credentials, which means it cannot produce that number by itself. Rather than assume a table size and present the result as a calculation, it separates what it can know from what it cannot:

  • Structure only — findings and ratios from the SQL alone. Deliberately no dollar figure.
  • I have the bytes — you supply the dry-run figure, we do exact pricing arithmetic against real regional rates.
  • Add my schema — an INFORMATION_SCHEMA extract lets us model bytes per table: fixed-width columns exactly, variable-width columns calibrated against the table’s real logical size rather than guessed.

Clustering is never modelled, because block pruning cannot be predicted before a query runs — even a dry run returns an upper bound on a clustered table. Where a partition filter cannot be turned into a partition count, the estimate assumes a full scan and says so, which overstates cost rather than flattering it.

What it looks for

11 detectable anti-patterns, each with its own page explaining the mechanism and the fix.

What SELECT * actually costs in BigQuery
BigQuery bills the columns you read, not the rows you return, so SELECT * is the most expensive way to write any query.
LIMIT does not reduce BigQuery query cost
Adding LIMIT 10 to a query changes what you see, not what you are billed. It is the most common cost misconception in BigQuery.
Querying a partitioned table without a partition filter
A partitioned table with no filter on its partition column scans every partition — usually the single largest avoidable cost in a BigQuery estate.
A partition filter that looks like pruning but is not
Filtering the partition column against a subquery or a joined column does not prune anything — BigQuery has to read every partition to evaluate it.
Wildcard tables without a _TABLE_SUFFIX filter
A wildcard table pattern with no _TABLE_SUFFIX constraint reads every matching table, which for daily-sharded data means the entire history.
A CTE referenced more than once is evaluated more than once
BigQuery does not materialize WITH clauses. A CTE used in three places runs three times, and bills three times.
Self-joins where a window function would do
Joining a table to itself reads it twice. A window function reads it once and is usually faster as well.
CROSS JOIN and joins with no equality condition
A join without an equality condition produces the Cartesian product. It rarely ends in a bill — it usually ends in a failed query after burning a lot of slot time.
The 10 MB minimum, multiplied by many small tables
BigQuery bills at least 10 MB per table referenced per query. Join forty lookup tables and you have bought 400 MB before reading any real data.
ORDER BY without LIMIT on a large result
A top-level sort with no LIMIT forces the whole result through a single worker. It is the most common cause of "resources exceeded".
COUNT(DISTINCT) where an approximation would do
Exact distinct counts require a full shuffle. APPROX_COUNT_DISTINCT is typically within 1% and dramatically cheaper in slot time.
Views defined with SELECT * impose their cost on every reader
A view that selects every column makes column pruning impossible for anyone querying it — even someone selecting a single field.
The same query, over and over, uncached
Repetition is where BigQuery bills add up. A $2 query on a 15-minute schedule is $5,760 a year.
Rewriting a table resets it to active storage pricing
Data untouched for 90 days drops to roughly half price automatically. Any write to the table puts all of it back at full price.

Frequently asked questions

How do I estimate the cost of a BigQuery query before running it?

The authoritative answer is a dry run: paste the query into the BigQuery console and read the validator message, or run bq query --dry_run. That returns exact bytes processed. This tool takes that figure and prices it, and separately finds the structural reasons the number is as large as it is — which the dry run does not tell you.

Why does this tool not just tell me the cost from my SQL?

Because it cannot honestly. Bytes processed depend on how much data sits in the columns your query touches, which is not in the SQL. Any tool that prints a dollar figure from SQL alone has assumed a table size, and that assumption is doing all the work. Give it your schema or your dry-run figure and it will do real arithmetic.

Does LIMIT reduce BigQuery cost?

No, not on a non-clustered table. LIMIT truncates the result after BigQuery has read the data it needs, so bytes billed are identical with and without it. To look at a sample cheaply, use table preview or bq head, which read no billable bytes.

How much does SELECT * cost in BigQuery?

It costs the total logical size of every column in the table, per run, regardless of how many rows you get back. On a wide table where you need four columns out of two hundred, that is roughly fifty times what the query needs to cost.

Why is my partition filter not reducing the bytes scanned?

Pruning happens at planning time, so the filter value has to be resolvable before any data is read. Literals and functions of literals qualify. A value coming from a subquery, a join, or a correlated reference does not, so every partition is read and the filter is applied afterwards. Resolve the value into a scripting variable or a query parameter first.

Is it safe to paste my SQL here?

This page has no backend. The analysis runs in your browser, nothing is uploaded, and no part of your query is written into the URL. You can confirm all of that in the network tab.

One query at a time is a slow way to find them all.

Finitizer ranks every query in your project by cost, groups them by shape so you see the repeated ones, and rewrites the expensive ones with an AI optimizer that shows the cheaper version side by side. Read-only and keyless.

Get a free savings analysisSee how Finitizer works