Google BigQuery

AddisDB queries BigQuery through its REST API with an OAuth2 access token. BigQuery bills by bytes scanned, which makes its dry-run API genuinely valuable — AddisDB uses it to tell you the exact scan size of a query before you run it.

Who it is for

BigQuery is serverless: there is no cluster to size, start or stop. You load data and query it, and Google allocates whatever compute the query needs. It handles enormous scans well and integrates tightly with the rest of Google Cloud.

Columnar storage plus per-query slot allocation is what makes that work, and it also explains the pricing: on-demand billing counts the bytes the columns you touched occupy, so SELECT * over a wide table can cost fifty times what the same query with three named columns does.

It fits analytics teams that want zero infrastructure, workloads that are bursty rather than constant, and organizations already using GA4, Ads or Firebase exports — which land in BigQuery natively.

Set up access

1. Note your GCP project id from the Cloud console.
2. Install the gcloud CLI, then run gcloud auth login and gcloud config set project YOUR_PROJECT_ID.
3. Generate an access token with gcloud auth print-access-token.
4. Make sure your account has the BigQuery Data Viewer and BigQuery Job User roles — you need both: one to read tables, one to run queries.
5. Note the dataset you work in most; it becomes your default.
6. Datasets are regional. A query cannot join a US dataset to an EU one, and the error will name the location rather than the problem.

# The token AddisDB needs
gcloud auth print-access-token

Connect from AddisDB

1. New Connection → BigQuery under Big Data / Warehouse. Port prefills to 443.
2. Put your project id in Host.
3. Set Database to project.dataset for a default dataset, or just the dataset name when the project is already in Host.
4. Paste the access token into the API key / token field.
5. Test, then Save.

Exact cost, before you run it

Click Estimate cost and AddisDB submits the query as a dry-run job. Dry runs scan nothing and cost nothing, but BigQuery returns the precise number of bytes the real query would process — so the estimate is not a guess, it is the number you will be billed on.

Use it as a feedback loop rather than a warning. Name your columns instead of selecting everything, put a predicate on the partitioning column, and re-estimate — the number usually drops by an order of magnitude, and you can see it drop before spending anything.

One caveat worth knowing: a dry run cannot price a query against a table whose size is unknown until it runs, so a query over a wildcard table set or an external source can estimate lower than reality.

Nested and repeated data

BigQuery tables often carry STRUCT and ARRAY columns — that is how GA4 and most Google exports are shaped. AddisDB decodes them into the grid and keeps the original shape on the JSON tab, and UNNEST is how you turn a repeated field into rows.

SELECT event_name, param.key, param.value.string_value
FROM   `project.analytics_123.events_*`
CROSS JOIN UNNEST(event_params) AS param
WHERE  _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
LIMIT  100;

What else AddisDB gives you

• The Big Data Console — a catalog browser for datasets and tables, a query pane, and a row cap on every preview.
• Nested and repeated fields (STRUCT and ARRAY) decoded into the grid, with the JSON tab for the original shape.
• The full safety model: read-only connections, prod tagging, destructive-statement detection.
• The Chart view, notebooks, ⌘K search, and AI querying grounded in your real datasets.
• Table sizes and row counts from __TABLES__, feeding the size alerts.