> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adriel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# FAQs
> Common questions, expected behaviors, and troubleshooting for the Google BigQuery data source.
## Why does my BigQuery query cost more than expected?
Each widget load that misses the cache issues a live query against the bound BigQuery table, and **every query is billed by Google Cloud** against the connected project's billing account. There is no incremental sync — data is fetched on demand — so more widgets, more manual refreshes, and broader queries all translate directly into more scanned bytes and higher cost.
The largest cost lever is narrowing how much data each query scans:
* **Map a date column in Blend Data settings.** Date-range filtering is applied automatically to the mapped column, so a partitioned table only scans the partitions inside the widget's date range.
* **Add a data-source pre-filter.** A `customFilters` WHERE fragment or a `filterColumn` condition narrows the scan before widget filters apply.
* **Use fewer widgets and fewer manual refreshes.** Each unfold action and each widget is a separate query.
Identical SQL statements are served from a **10-minute** result cache, so repeated identical loads within that window do not re-scan BigQuery. Cost is driven by the queries that miss the cache.
For the full billing model and scan-reduction guidance, see the [data reference](/data-sources/g-n/google-bigquery/data-reference).
## Why did my BigQuery data source stop showing data or get disconnected?
BigQuery has no background sync — a data source that "stops updating" has usually hit an error on its next live query. Some errors disconnect the data source automatically; others surface on the widget without disconnecting.
The following conditions **disconnect the data source automatically** and require attention in the source or a reconnection:
| What happened | Typical cause |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Google authorization expired (`invalid_rapt`) | The Google session ended and needs re-authentication (for example, Advanced Protection re-auth). Reconnect the data source. |
| Access denied on the table or dataset | The connected identity lost permission on the bound table or dataset. |
| Dataset not found | The bound dataset was renamed or deleted. |
| Table found in a different region | The bound table no longer resides in the dataset's expected region (`Table ... was not found in location ...`). |
A **table-not-found** error on the bound table (`Not found: Table`) surfaces as an error but does **not** disconnect the data source on its own — recreate or repoint to the correct table.
Re-authorization is handled through the connection flow, not by editing the data source. See [How to connect Google BigQuery to Adriel](/data-sources/g-n/google-bigquery/how-to-connect) for the reconnection steps.
## Why is my custom SQL returning `SUM_TOO_BIG_TO_AGGREGATE`?
`SUM_TOO_BIG_TO_AGGREGATE` means an integer `SUM` aggregation overflowed BigQuery's `INT64` range. The connector does **not** auto-cast numeric columns to `FLOAT64` for summation, so a large integer column summed across many rows can exceed the limit and fail the query.
The automatic `CAST(x AS FLOAT64)` wrapping applies only when `sum`, `min`, or `max` is used on a `STRING` column. Native numeric columns are summed as-is, which is why the overflow surfaces.
To work around it:
Expose the table through a BigQuery view that casts the offending column to `FLOAT64` or `NUMERIC`, then bind the data source to that view. Aggregation then runs against a type that will not overflow.
Tighten the widget date range or add a data-source pre-filter so fewer rows are aggregated per query.
This error does not disconnect the data source — it fails only the query that overflowed.
## Why does my widget show fewer rows than the table, or flag data as incomplete?
Widget results are capped at **1,000 rows per query** by default (`sqlLimit`, configurable per data source). The cap is applied after grouping, and it is intentional for stability and cost control.
When a result reaches the cap, the response is flagged with `TOO_MUCH_DATA_REQUESTED_INCOMPLETE`, meaning some rows may be missing. To bring the result under the cap:
* Add breakdowns or filters that reduce the number of grouped rows.
* Tighten the widget date range.
* Pre-aggregate or pre-filter on the BigQuery side through a view.
## Why don't new columns or recent row changes appear right away?
Two caches sit in front of BigQuery, so recent changes can lag:
* **Result cache (10 minutes).** Two identical SQL statements issued within a 10-minute window return the same cached result. Rows changed in BigQuery during that window may still show the previous values until the cache expires.
* **Field metadata cache (up to 24 hours).** New columns added on the BigQuery side become selectable only after the field cache refreshes.
This is expected behavior, not a failure. Waiting for the relevant cache to expire brings the new columns or updated rows through on the next query.
## Related
* [Google BigQuery data reference](/data-sources/g-n/google-bigquery/data-reference) — field type mapping, query model, filters, and limits
* [How to connect Google BigQuery to Adriel](/data-sources/g-n/google-bigquery/how-to-connect) — authorization and reconnection steps
* [Snowflake data reference](/data-sources/o-z/snowflake/data-reference) — alternative cloud data warehouse
* [PostgreSQL data reference](/data-sources/o-z/postgres/data-reference) — alternative SQL database
* [Redshift data reference](/data-sources/o-z/redshift/data-reference) — alternative cloud data warehouse