Source connector

Google BigQuery connector

Google BigQuery integration for databases, warehouses and BI tools

Serverless analytics warehouse on Google Cloud. Datrise captures Google BigQuery entities such as datasets, tables, views, query jobs, table schemas and partitions, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The Google BigQuery API v2 (Standard SQL) + Storage Read API authenticates with OAuth 2.0, service account, and Google BigQuery caps calls at 100 concurrent interactive queries per project (default 200 TiB/day query-bytes-billed quota), 100,000 load jobs per project per day, extract/export jobs capped at 50 TiB exported per day, on-demand pricing capped at 2,000 slots, and most API methods limit to 100 requests/second per user (`jobs.get` is the exception at 1,000/sec).

Of the 6 objects, 5 sync as upserts keyed on the primary key and 1 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `bigquery_datasets`) with a schema derived from the Google BigQuery API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the Google BigQuery pipeline page, and join the waitlist to get the Google BigQuery connector with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What Google BigQuery data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
datasets	bigquery_datasets	Upsert by primary key, incremental on updated-at
tables	bigquery_tables	Upsert by primary key, incremental on updated-at
views	bigquery_views	Upsert by primary key, incremental on updated-at
query jobs	bigquery_query_jobs	Append-only, incremental by timestamp
table schemas	bigquery_table_schemas	Upsert by primary key, incremental on updated-at
partitions	bigquery_partitions	Upsert by primary key, incremental on updated-at

Google BigQuery API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	Google BigQuery API v2 (Standard SQL) + Storage Read API
Authentication	OAuth 2.0, service account — Standard Google Cloud IAM: an OAuth 2.0 user token or, far more commonly for pipelines, a service account key/attached identity with `bigquery.dataViewer` and `bigquery.jobUser` roles.
Pagination	token — `jobs.getQueryResults` and `tabledata.list` return an opaque `pageToken` to fetch subsequent pages; the Storage Read API instead streams results as Avro/Arrow without page tokens.
Rate limit	100 concurrent interactive queries per project (default 200 TiB/day query-bytes-billed quota), 100,000 load jobs per project per day, extract/export jobs capped at 50 TiB exported per day, on-demand pricing capped at 2,000 slots, and most API methods limit to 100 requests/second per user (`jobs.get` is the exception at 1,000/sec)
Incremental cursor	Not published
Webhooks	No
Bulk export	Yes — EXTRACT job to Google Cloud Storage (CSV, JSON, Avro, or Parquet)
Deletes detectable	No

Official API reference

What bites when replicating Google BigQuery

There is no native CDC or `updated_at` guarantee on BigQuery tables, so incremental extraction is only as reliable as whatever timestamp column the source table's own producer chose to maintain (or omitted).
Time Travel only covers the past 7 days by default (configurable down to 2 days) via `FOR SYSTEM_TIME AS OF`, so it can reconstruct recent deletes/overwrites but is not a durable change feed a pipeline can depend on for historical replay.
Export jobs are capped at 50 TiB exported per project per day; a table larger than that in a single day has to be extracted across multiple days or split by partition.
Concurrent interactive queries are capped at 100 per project shared across every job and every user in that project, so a connector running many parallel extraction queries can starve other consumers of the same project's quota.

Compare this against every other documented API

Popular destinations for Google BigQuery

Choose a destination below to open the ready pipeline page.

A
Airtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline
A
Amazon Athena
Serverless SQL over S3 data lake tables.
View pipeline
A
Amazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline
A
Amazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline
A
Amazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline
A
Amazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline
A
Apache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline
A
Azure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline
A
Azure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline

Google BigQuery connector FAQ

What Google BigQuery data does the connector extract?: 6 objects: datasets, tables, views, query jobs, table schemas and partitions. Each lands in its own table with types preserved; history-style objects (1: query jobs) load as append-only streams.
Is the Google BigQuery integration incremental?: Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
Where can I load Google BigQuery data?: Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each Google BigQuery → destination pair has its own page with the object-to-table mapping.

Related sources

Other sources in the same category, each with its own connector page.

Early access

Launch your Google BigQuery pipeline with guided onboarding

Join the waitlist to get priority access for Google BigQuery integrations with guided setup, schema-aware mapping, and production-grade incremental sync.