Skip to main content

​
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.

​
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: 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 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:
1

Cast the column in a BigQuery view

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.
2

Narrow the range being summed

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.