BigQuery cost and quota limits
BigQuery on-demand pricing bills by bytes scanned, and the service enforces quotas on concurrent and daily activity. GA4 export tables are date-sharded, so a query that ignores the date suffix scans every day and runs up cost; quota limits can reject jobs at peak. This page explains how cost and quotas affect GA4 export work and how to keep scans and jobs bounded.
What drives cost and rejection
On-demand BigQuery charges by the volume of data a query reads, not the rows returned, and SELECT * over wide nested rows reads far more than a few columns would. GA4 shards events into one table per day, so a wildcard without a _TABLE_SUFFIX filter scans the entire history. Separately, BigQuery enforces quotas — concurrent queries, daily query bytes for some setups, and streaming insert limits — that can reject work at busy times.
Both show up as 'the export is failing' when the cause is scan size or a quota ceiling.
- Billed by bytes scanned, not rows returned
- Wildcards without date filters scan all shards
- Quotas cap concurrency and streaming throughput
Keeping it bounded
Filter on _TABLE_SUFFIX (or partition pseudo-columns) to read only the dates you need, and select named columns instead of *. Materialize frequently used aggregates so dashboards do not re-scan raw events. Watch quota errors and back off or batch rather than retrying into the same ceiling. Set a maximum-bytes-billed guard on ad-hoc queries to fail loudly before a runaway scan.
This is operational hygiene, separate from whether the rows themselves are correct.
How it appears in analytics and logs
A surprise bill or a rejected job on the export usually means a query scanned all date shards or hit a concurrency or daily quota, not that data changed.
Diagnostic use case
Keep GA4 BigQuery export queries affordable and within quota by scanning only needed dates and columns rather than whole tables.
What WebmasterID can help detect
WebmasterID serves common analytics questions without ad-hoc full-table scans, reserving the export for queries that truly need it.
Common mistakes
- SELECT * across all date shards of the export.
- Re-scanning raw events for every dashboard load.
- Retrying straight into a quota ceiling without backoff.
Privacy and accuracy notes
Cost controls are operational and touch no visitor identity. This page is educational, not legal advice.
Related pages
- Event parameter unnesting in BigQuery
In the GA4 BigQuery export, event_params is an array of key/value records where the value lives in one of string_value, int_value, float_value, or double_value. Reading a parameter requires UNNEST plus a key filter, and doing it carelessly multiplies rows so event counts inflate. This page explains how to unnest event parameters correctly and why the wrong join over-counts.
- Quota and throttling
GA4's Data API meters usage with token buckets per property, charging more tokens for larger and more complex queries. Concurrent requests are also capped. Pipelines that fan out too many or too-expensive queries exhaust the quota and get throttled with quota errors, so an export can fail partway and leave a gap. This page explains the quota model and how to stay under it.
- API export limits
Programmatic exports through the GA4 Data API are bounded: a single response returns up to a fixed number of rows, and each query is limited in how many dimensions and metrics it may combine. Pulls that ignore these limits truncate without obviously failing, producing partial datasets that look complete. This page explains the row and field caps and the pagination that avoids silent truncation.
- Website observability
Watch pipeline cost and quota as operational signals.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.