If your source of truth is BigQuery but a team or tool needs the same data in Snowflake, Data Sync moves it without a custom pipeline script.
No credit card. 14 days. Cancel in one click.
Quick answer: Open Pipelines, Build, and New Sync. Pick BigQuery as the source connection and table, Snowflake as the target, and drag fields across, or use AI Map. Choose Insert, Update or Upsert, run a Dry Run to preview, then save it as a scheduled job. Pipelines tier.
BigQuery and Snowflake don't talk to each other directly. If a reporting tool, a teammate, or a compliance requirement means the data also needs to live in Snowflake, someone has to move it, on a schedule, reliably, without dropping rows on a schema change. That's what Data Sync is for: a mapped, repeatable move from one to the other, not a one-off export.
Say you're moving a daily customer summary from BigQuery into a Snowflake table another team's dashboard reads from. The source is:
SELECT customer_id, plan, lifetime_value, last_active FROM `my-gcp-project.crm.customer_summary`;
Map customer_id to the target's CUSTOMER_ID, set MODE to Upsert, and choose CUSTOMER_ID as MATCH ON. Every run inserts new customers and updates existing ones in place, no duplicate rows accumulating.
Data Sync maps fields you tell it to map; it won't silently add a new BigQuery column to the Snowflake target on its own. If the source table gains a column you want mirrored, add it to the Snowflake table and update the mapping. Treat schema changes on either side as a manual step, not something the sync handles automatically.
For an initial sync of a big table, run it once manually with Dry Run, then a real run, before turning it into a recurring job. Watching the first full run land correctly is worth the extra few minutes, especially before a schedule starts running it unattended every night.
Run Dry Run first and read the preview before anything writes. After a real run, check the job's history: a clean run shows rows synced with no errors; a partial one lists which rows failed and why, usually a type mismatch between the two schemas.
| If you see | Fix |
|---|---|
| Choose at least one key field | Pick a MATCH ON column for Update or Upsert. |
| Duplicate key values in source | Pick MATCH ON columns that uniquely identify rows in the BigQuery source. |
| Records synced, with errors listed | Usually a type mismatch; read the listed error for the exact field. |
For the general Data Sync walkthrough, see the Sync data into BigQuery or Databricks tutorial, the same mapping and mode logic runs in reverse when BigQuery is your target instead.
A sync named "Sync 3" is hard to recognize six months on. Name it for what it actually moves, "BigQuery customers to Snowflake," so anyone looking at the Pipelines list, including future you, knows what it does without opening it to check.
If the BigQuery source table gains new columns you'd like mirrored into Snowflake, the mapping doesn't pick them up automatically, you add the new field on the Snowflake side and update the mapping by hand. Treat the sync as a snapshot of a mapping you set deliberately, not something that tracks schema drift on its own.
After updating a mapping to include a new field, run Dry Run again before letting the next scheduled run go out unattended. It costs a minute and catches a mismatched type before it becomes a job failure at 3 AM instead of a preview you caught in daylight.
If a sync built for one table starts feeding a second one too, rename it to reflect what it actually does now rather than leaving the original, narrower name in place. A stale name is a small thing that quietly makes a Pipelines list harder to trust over time.
See also: Integrations CSV to Snowflake on Mac Sync Databricks to Snowflake.
Either. Run it manually from Build, or save it as a job with its own schedule under Pipelines.
Data Sync inserts and updates; it doesn't delete rows from the target that disappeared from the source. Handle deletions separately if that matters for your use case.
Yes, write SQL as the source instead of picking a table directly, and filter however you need.
Pipelines. Studio covers querying, the explorer and the Ask panel; Data Sync, scheduling and Watch This are Pipelines features.
14-day free trial, no card. Both connections, one mapped sync.
No credit card. 14 days. Cancel in one click.