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.
What it is
LIMIT is applied after BigQuery has read the data it needs to answer the query. On a non-clustered table the bytes scanned — and therefore the bill — are identical with and without it.
Why it costs money
- The engine must read the referenced columns to produce any result at all; LIMIT only truncates the output stage.
- The intuition comes from row-store databases, where an indexed LIMIT really can stop early. BigQuery has no such index.
- On a clustered table LIMIT can sometimes reduce scanning through block pruning — "sometimes" is not something to plan a budget around.
Worked example
Expensive
SELECT * FROM `analytics.events` LIMIT 10Cheaper
SELECT * FROM `analytics.events` WHERE event_date = CURRENT_DATE() LIMIT 10The arithmetic. The first bills the full table — 2 TiB, $12.50 — to show you ten rows. The second prunes to one partition and bills ~5 GiB, about $0.03. Same ten rows.
How to fix it
- 1Use table preview in the console, or `bq head -n 10`. Both read zero billable bytes.
- 2If you need a real query, add a partition filter — that is what actually reduces the scan.
- 3Set a maximum bytes billed limit on the job so an exploratory query cannot run away.
The analyzer detects this one. Paste your query into the BigQuery Query Cost Analyzer and it will point at the exact line.
Fixing one query is satisfying. Fixing the pattern is the win.
Finitizer finds every instance of this across your BigQuery job history, ranks them by what they actually cost, and keeps checking after you have fixed them.