Skip to content

Stacksync × Supabase Miami: AI-Native OperationsOct 13Reserve your spot

Data warehouse · Two-way sync platform

BigQuery connector for two-way sync.

Keep BigQuery and your business systems aligned with Stacksync. Sync Tables within the connector’s object and field requirements, with two-way sync for eligible records.

  • Configure field mappings and sync direction
  • Inspect and resolve record errors in one dashboard

Adopted by fast-scaling companies moving mission-critical data in real time

Case study
Migrated from MuleSoft
Case study
Migrated from Celigo
Migrated from Heroku Connect
Migrated from Matillion
Case study
Migrated from Fivetran
Case study
Migrated from Celigo
Record types

BigQuery objects and coverage.

Start with the records your workflow needs. Object-specific permissions and operation limits are shown alongside the available coverage.

Tables
Check object and field eligibility in the setup guide.

Read the BigQuery object and setup guide

Connection setup

BigQuery connection requirements.

Check the account access and change-detection requirements for your environment. Your system administrator can help confirm permissions before the first sync.

Connection method
GoogleSQL via the BigQuery REST API, client libraries, JDBC/ODBC drivers, and the Storage Read/Write APIs
Account access
Dedicated Google Cloud service account and JSON key; enable the APIs and grant the roles in the authorization guide.
How changes are detected
The setup provisions notification services using Eventarc and Cloud Run in the customer Google Cloud project.

Sync directions

  • Read data Documented
  • Write data Documented
BigQueryStacksync setup guide
Setup prerequisites for your administrator
  • Enable BigQuery, Cloud Run, Cloud Resource Manager, and Eventarc APIs in the target project.
  • Create a dedicated service account with the roles in the authorization guide and supply its credentials through Stacksync.

Documentation checked September 15, 2026.

Setup guides and technical references

Integration design

Match records and fields for your BigQuery integration.

Choose the dataset grain, stable business key, and model refresh schedule. If results update an application, restrict writes to fields owned by the analytical process.

Use your account’s actual field names when applying these matching and dependency checks.

Explore record matching and field-mapping checks
BigQuerySource record IDKeep the account and record type
Record matchingSource ID ↔ destination IDLink the same record across systems
Selected destinationDestination record IDPreserve its local key and rules
Conceptual identity model. Keep source and destination IDs linked so an update reaches the right record. Confirm the supported sync direction separately.
Match the same record in both systems
Define the business grain and a stable, unique key for every selected table. Test a second delivery of the same logical row before using warehouse results to update an application.
Load related records in the right order
Choose a table for the sync dataset. The documented connector excludes ordinary and materialized views; materialize a suitable dataset only after agreeing on ownership and refresh behavior.

Mapping checks by record type

Tables

Check the object requirements below

Identity
Define a stable key for each table row or document and retain the external application key separately. Confirm the selected connector’s exact key requirements before altering a schema.
Fields to consider
Local record key · External application ID · Required business fields · Parent record references
Related records to resolve first
Choose a table for the sync dataset. The documented connector excludes ordinary and materialized views; materialize a suitable dataset only after agreeing on ownership and refresh behavior.
Test before going live
Test repeated delivery, a changed external value, a missing parent, an incompatible type, and a schema change using a representative record.

Download the field-mapping workbook (CSV) to capture the actual API fields, matching keys, owners, and test results. Use it as you build with your team or a Stacksync engineer.

Setup and validation

Validate the BigQuery integration in four steps.

The destination can trace a value to its source dataset and computation time, and a model refresh does not create duplicate operational records.

View the four setup tests and expected results
  1. Confirm the intended BigQuery account and grant

    Use the documented setup with the intended account and environment. Check that the authorizing user can grant access to the selected objects; test reauthorization without changing the mapped record identity.

    Expected result: The connection reaches the intended account, and the integration owner can renew or revoke the grant through the agreed procedure.

  2. Test a table change after provisioning

    Confirm the required BigQuery, Cloud Run, Cloud Resource Manager, and Eventarc APIs, then change a test row and observe its permitted destination.

    Expected result: The service account can access the intended table and the notification path operates in the correct project.

  3. Test writes in the directions you need

    Select one eligible BigQuery object and writable field. Test the required create/update direction, an invalid value, and a repeated delivery. Check object-specific restrictions before enabling the return path.

    Expected result: The selected operation is confirmed, addresses the intended record, and exposes rejected values for repair.

  4. Test recovery and name the support owner

    Interrupt a non-production transfer, restore the connection, and reconcile the selected BigQuery records. When using Stacksync’s Retry to sync action, check the latest source value: the retry re-reads current source state rather than replaying an immutable historical event.

    Expected result: The records have the expected current values, repeated delivery creates no duplicate business record, and your team knows who handles unresolved errors.

Use the production-readiness checklist to record test results, assign support owners, and agree on when to go live.

Troubleshooting

Troubleshoot your BigQuery integration.

Diagnose record matching, delayed changes, and rejected operations
Authorization succeeds but later changes are missing
Check the service account roles and provisioned Eventarc/Cloud Run services. Confirm that the selected object is a supported table, not a view.
The first load looks correct but later results differ
The setup provisions notification services using Eventarc and Cloud Run in the customer Google Cloud project. Measure the original source change, its capture, and the destination observation separately. Confirm whether the affected object is incremental, historical-only, or subject to a special refresh cycle.
One operation succeeds while another is rejected
Check the specific BigQuery object, field permissions, required references, and allowed operation. A successful read does not establish that a create, update, deletion, or business action is available.

Review retry, replay, and recovery behavior before repeating an operation that may already have succeeded.

Review your BigQuery workflow with an engineer

FAQ

BigQuery connector FAQ

How should I plan an integration with BigQuery?

Use eligible tables and validate the project services that support change notifications. Stacksync supports two-way sync for eligible objects. Start with one workflow, agree on which fields each system owns, then test initial data, later changes, and recovery before expanding.

Can the BigQuery connector write changes back?

Stacksync supports reads and writes for eligible BigQuery objects. Check the selected fields, account permissions, and the other system’s connector. Confirm the required BigQuery, Cloud Run, Cloud Resource Manager, and Eventarc APIs, then change a test row and observe its permitted destination.

Which identifiers should I preserve for BigQuery data?

Define the business grain and a stable, unique key for every selected table. Test a second delivery of the same logical row before using warehouse results to update an application.

Which related records should I load first for BigQuery?

Choose a table for the sync dataset. The documented connector excludes ordinary and materialized views; materialize a suitable dataset only after agreeing on ownership and refresh behavior.

What should I check if BigQuery data is missing or delayed?

Check the service account roles and provisioned Eventarc/Cloud Run services. Confirm that the selected object is a supported table, not a view.

How should I compare integration methods for BigQuery?

Compare a vendor-native option if one exists, Stacksync, and a custom API or export against the same Tables workflow. Stacksync supports two-way sync for eligible objects. Test record matching, related data, update delay, and recovery. Include the ongoing work to handle schema changes and errors; a one-time export may be enough for a single copy.

Explore BigQuery connections

Choose the other system in your workflow. Each guide explains the connection options, available operations, field mapping, and setup checks for that pair.

290 integration guides

SECURITY

Security teams trust Stacksync

As a data company, we understand the importance of keeping your data secure. Stacksync is built with security best practices to keep your data safe at every layer, and is DPF-certified for US, EU, UK and CH data transfers.

SOC 2 Type II
ISO 27001
HIPAA BAA
GDPR
CCPA
DPF US-EU-UK-CH
→ SECURITY WITH BENEFITS

SSO & SCIM

Let your users access Stacksync from your centralized user management systems. Works with Okta, Azure, Google SSO and more.

Alerts

Immediately get alerted about record syncing issues over email, Slack, PagerDuty and WhatsApp. Resolve issues from a centralized dashboard with retry and revert options.

Secure connection options

Securely connects to your systems with:

Coworkers laughing in front of a laptop in a casual office setting

Connect the systems your business runs on.
Build your next workflow with Stacksync.