BigQuery Cost Estimator

Playground · simulator · query audit · no sign-up · shareable link

BigQuery's on-demand pricing bills by bytes scanned, not by query complexity or rows returned — which means the query validator's "this query will process X bytes" line is the only number that predicts your bill. This tool converts that estimate into a cost per query and per month, simulates how column selection and partition pruning shrink a scan, and audits a pasted query for the cost smells (SELECT *, missing partition filters, LIMIT mythology) that cause surprise bills. All three modes run entirely in your browser.

Formula

Cost = (Bytes Scanned ÷ 1 TB) × Price per TB, minus the free monthly tier

Runs per month1

1 = one-off · 30 = daily dashboard · 730 = hourly refresh

Cost per run

$0.3052

0.0488 TB scanned, at $6.25/TB on-demand

Estimated monthly cost

$0.00

First 1 TB/month free, applied before this total.

Monthly bytes vs free tier

0.05 TB/month · 0.05 TB free · 0.00 TB billable

Monthly cost as refresh frequency grows — watch the kink where the free tier runs out

$0$54$108$162$217152060/mo200/mohourly

Estimate only, using on-demand list pricing ($6.25/TB) as of writing — not a live quote. Flat-rate/capacity pricing bills differently; see the slot glossary entry.

Inputs

What each field wants

Validator mode — bytes scanned
Copy the figure from the BigQuery UI validator (the green tick, top right of the editor), from a --dry_run on the bq CLI, or from totalBytesProcessed on a jobs.query dry run. It is an estimate the engine produces without executing anything, and it is free to obtain.
Runs per month
Set this to 1 for a one-off exploration. For a scheduled query set it to the number of runs in a month (hourly = ~730, daily = ~30). For a dashboard tile, multiply expected daily views by the number of tiles that fire the same query — this is where surprise bills come from. Drag the slider and watch the cost curve bend at the free-tier kink.
Simulator mode — table, columns, partitions
No validator figure? Describe the table instead: its size, how many of its columns you SELECT, and what share of partitions your date filter touches. The scan estimate is table × column fraction × partition fraction — the two cheapest optimisations in BigQuery, made draggable.
Audit mode — paste your query
Paste any query for an instant cost-smell check: SELECT *, missing partition filters, LIMIT (which never cuts cost), JOIN fan-out risk, ORDER BY without LIMIT. Nothing leaves the browser — the audit is pure pattern matching on your text.
Methodology

How this number is derived

Bytes scanned, not rows returned

On-demand BigQuery reads whole columns. A SELECT event_name FROM events that returns 12 rows still scans every value in the event_name column across every partition the query touches. LIMIT does not reduce the bill — it truncates the result after the scan has already been paid for.

The dry run is authoritative, within limits

The estimate the validator gives is what you will be billed for a standard on-demand query, with two caveats: queries reading from a table with a materialized view or a BI Engine reservation may scan less, and clustered tables often scan less than estimated because block pruning only resolves at execution time. The estimate is therefore an upper bound for clustered tables and an exact figure for plain partitioned ones.

The free tier is monthly and account-wide

The first 1 TB of query data processed per month is free, per billing account — not per project, not per user. This calculator subtracts it once from the monthly total, which is the right behaviour if this query is your only workload and optimistic if it is not. If you have other queries running, treat the free tier as already consumed and read the "cost per run × runs" figure instead.

Minimum billing increments

BigQuery bills a 10 MB minimum per table referenced by a query, and a 10 MB minimum per query. For the tiny queries where that matters, the cost is a rounding error either way; this tool does not model the floor.

Worked example

A dashboard tile that costs more than the dashboard

Query
Daily sessions from a GA4 export, 14 months of data, no date filter
Validator says
2.4 TB will be processed
Refresh
Dashboard auto-refreshes hourly, 730 runs/month
Cost per run = 2.4 TB × $6.25/TB = $15.00
Monthly bytes = 2.4 TB × 730 runs = 1,752 TB
Billable after free tier = 1,752 − 1 = 1,751 TB
Monthly cost = 1,751 × $6.25 = $10,943

One un-filtered tile, refreshing hourly, is a ~$10.9k/month line item. Adding WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) to a date-partitioned table cuts the scan to roughly 170 GB per run — about $780/month, a 93% reduction from one WHERE clause.

Reference

What a scan size typically means

Rough orientation for a mid-sized e-commerce GA4 export plus ad-platform tables. Your data volume moves these substantially.

Under 1 GB~$0.006Aggregate table or a well-pruned single-day query. Effectively free.
10–50 GB$0.06 – $0.31A month of filtered events with a handful of columns. Normal working range.
200–500 GB$1.25 – $3.13A year of events, or a month with SELECT *. Worth a second look if it is scheduled.
1 TB+$6.25+Almost always an unfiltered scan of a date-partitioned table. Fix the WHERE clause before scheduling it.
Scope

What this assumes, and what it doesn't model

Assumptions

  • On-demand (per-byte) pricing, not a flat-rate or Editions capacity commitment.
  • US multi-region list price of $6.25 per TB. Other regions are priced differently and Google changes list prices periodically — check the current rate for your region before quoting this to anyone.
  • The bytes figure you enter is the validator's estimate for the query as written, including every column in the SELECT list.
  • The full monthly free tier is available to this query.

Deliberately not modelled

  • Does not model storage cost — you also pay per GB-month for the data at rest, active and long-term at different rates.
  • Does not model streaming inserts, BI Engine reservations, or the free operations (loads, exports, copies, metadata queries).
  • Does not apply the 10 MB per-query and per-table billing minimums.
  • Does not convert to your local currency. The number is USD because Google's list price is quoted in USD.
  • Cached query results are free and are not modelled here — an identical query re-run within 24 hours against unchanged tables usually costs nothing.
FAQ

Common questions

Does LIMIT reduce my BigQuery bill?

No. LIMIT truncates the result set after the scan has already happened, so a query with LIMIT 10 costs exactly the same as the same query without it. The only things that reduce bytes scanned are selecting fewer columns, filtering on a partition column, and reading from a smaller table.

Why does SELECT * cost so much more than naming columns?

BigQuery is a columnar store: it reads only the columns your query references. SELECT * references all of them, so a table with 80 columns costs roughly 80 times a single-column query on the same rows. On a GA4 export with nested RECORD fields, the multiple is often larger.

How do I get the bytes figure without running the query?

The BigQuery console shows it in the top-right validator as soon as the query parses. On the CLI, bq query --dry_run --use_legacy_sql=false '<query>' returns it. Via the API, set dryRun: true on a jobs.query request and read totalBytesProcessed. All three are free and instant.

Can I put a hard cap on what a query is allowed to cost?

Yes — maximum_bytes_billed fails a query outright if it would exceed the byte limit you set, rather than running it and billing you. Set it as a default at the project level, and you have converted surprise bills into loud errors.

Is flat-rate pricing cheaper?

It becomes cheaper at high, steady volume. Capacity pricing bills for slots (compute) over time rather than bytes scanned, so it flattens spiky costs and caps the downside of one badly-written query. The crossover point depends on your usage pattern more than your total spend — compare a month of your actual on-demand bill against the cost of the smallest reservation that keeps your queries acceptably fast.

Last reviewed August 28, 2026.