BigQuery to Snowflake migration without hand-written export jobs

The BigQuery to Snowflake migration path from Adapters copies tables, casts BigQuery types to their Snowflake equivalents, and loads on an incremental schedule, so you can run both warehouses in parallel during a cutover instead of freezing reporting for a big-bang export. Field mapping is no-code, so try it against sample records in the live demo.

Try it in the live demo

No credit card required.

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Last updated September 2026

What running BigQuery to Snowflake by hand costs you

A one-shot export to cloud storage and COPY into Snowflake freezes reporting during the cutover, and any table that changes mid-migration has to be redone by hand.
BigQuery and Snowflake disagree on types: BigNumeric precision, nested and repeated RECORD fields, and the case-insensitive versus quoted-identifier rules all need deliberate handling or numbers, structs, and column names land wrong.
Dashboards and dbt models have to be validated against both warehouses before you switch, which means keeping the two in agreement for weeks, not copying once.

The field mapping, out of the box

These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.

Input / BIGQUERY

Output / SNOWFLAKE

orders.order_id

ORDERS.ORDER_ID

orders.total_amount

ORDERS.TOTAL_AMOUNT

orders.created_at

ORDERS.CREATED_AT

orders.line_items

ORDERS.LINE_ITEMS

customers.email

CUSTOMERS.EMAIL

orders.updated_at

ORDERS.LOADED_AT

Transforms included

BigQuery NUMERIC casts to Snowflake NUMBER(38,9) and BIGNUMERIC to NUMBER at its declared precision, STRUCT and ARRAY RECORD columns land as VARIANT so nested payloads survive the trip, TIMESTAMP stays UTC so no hour shifts on the way across, and STRING maps to VARCHAR. Incremental runs use an updated-at watermark per table, target tables cluster on the load date, and writes MERGE on the primary key so you can re-run a window during parallel validation without duplicating a single row.

BigQuery to Snowflake in depth

The mirror of the Snowflake to BigQuery route, and not simply the same problems reversed. From Google Cloud and Snowflake documentation, checked 31 August 2026.

Case sensitivity becomes case folding

BigQuery preserves the identifier you wrote and is case sensitive about it. Snowflake folds unquoted identifiers to UPPERCASE. A BigQuery table named orderItems becomes ORDERITEMS in Snowflake unless every reference is quoted, at which point every downstream query has to quote it forever. Normalize to a single convention during the load rather than carrying mixed casing into the warehouse.

NUMERIC to NUMBER needs the scale written down

BigQuery NUMERIC carries 38 digits of precision and 9 of scale. Snowflake NUMBER without arguments defaults to (38,0), no scale at all. Load a BigQuery NUMERIC money column into a default Snowflake NUMBER and every value is rounded to a whole unit, quietly. Declare NUMBER(18,2) or match the source scale explicitly. This is the defect most likely to reach a finance dashboard.

Snowflake has hard value size ceilings

Snowflake caps VARIANT, VARCHAR and ARRAY at 128 MB and BINARY at 64 MB, and VARCHAR defaults to 16 MB when no length is given. BigQuery is comfortable with rows up to 100 MB for CSV and JSON loads, so a wide JSON payload that BigQuery stores without complaint can exceed a Snowflake column limit on arrival. Check the maximum length of your largest string and JSON columns before designing the target schema.

Export file sizing decides the load time

Snowflake recommends staged files of 100 to 250 MB compressed and does not recommend files of 100 GB or more. The default COPY timeout is 24 hours, which sounds generous until one enormous gzip file loads on a single thread. BigQuery exports naturally shard into many files when you use a wildcard destination, and that default is the one you want. Do not consolidate them.

Partitioning does not carry across

A BigQuery table partitioned by ingestion time or by a date column has no automatic equivalent in Snowflake, which uses micro-partitions chosen by the engine and optional clustering keys. Recreating the partition column as an ordinary column and setting a clustering key on it is usually right. Copying the partitioning strategy literally is usually wrong and costs money on every query.

Snowpipe changes the shape of the pipeline

Snowpipe lands staged files within about a minute of arrival, which makes a continuous export from BigQuery into cloud storage a genuinely near real time pattern rather than a batch one. That is a different design from a scheduled bulk COPY and has a different cost profile. Choose deliberately rather than defaulting to whichever the first tutorial used.

Reconcile on values, never on row counts

Every failure described above preserves the row count exactly. Rounded money, truncated strings and mis-cased identifiers all produce a table with the right number of rows in it. Compare the SUM of every numeric column, the MIN and MAX of every timestamp, and a hash of the keys. A green row-count report is the most misleading artifact in a warehouse migration.

What we do about all of it

The mapping is declared per field with the Snowflake type and its scale written down rather than inferred, exports are staged in the recommended size range, and the incremental run merges on the key so a replay cannot double-count. The full picture for a one-time warehouse move, including how the pricing models behave when the project overruns, is on our data migration tools page.

How it goes live

Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.

STEP 01

Pick the pair

Connect BigQuery and Snowflake with scoped credentials. About a minute each.

STEP 02

Confirm the mapping

The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.

STEP 03

Schedule the sync

Hourly down to every minute, with retries, alerting, and a full log on every run.

Prefer to understand the moving parts first? Our long-form guide to the BigQuery to Snowflake migration guide covers the field-by-field detail, the failure cases, and what changes at volume.

Try it in the live demo Preloads BIGQUERY → SNOWFLAKE with sample records

BigQuery to Snowflake sync: common questions

How do I move data from BigQuery to Snowflake?

Export or read the BigQuery tables, land them in cloud storage as Parquet, and load into Snowflake with COPY, or use a connector that does both steps and keeps them incremental. Run the two warehouses in parallel while you port queries, and compare row counts and column sums per table before you cut anything over.

What are the biggest BigQuery to Snowflake migration challenges?

SQL dialect, nested data and cost model. BigQuery's STRUCT and ARRAY columns have to become VARIANT, OBJECT or ARRAY in Snowflake, and any query using UNNEST needs rewriting against LATERAL FLATTEN. The cost model also inverts: you stop optimizing for bytes scanned and start optimizing for warehouse size and idle time.

How do BigQuery types map to Snowflake?

STRING becomes VARCHAR, INT64 becomes NUMBER(38,0), FLOAT64 becomes FLOAT, NUMERIC and BIGNUMERIC become NUMBER with explicit precision, BYTES becomes BINARY, and BOOL becomes BOOLEAN. For time, BigQuery TIMESTAMP is an absolute instant in UTC so it maps to TIMESTAMP_TZ or a UTC TIMESTAMP_NTZ, while DATETIME carries no zone and maps to TIMESTAMP_NTZ. STRUCT, ARRAY and JSON all land as VARIANT.

Do you need to change SQL when migrating from BigQuery to Snowflake?

Yes, though less than people fear for plain analytical queries. The rewrites cluster in three places: nested data access, date and time functions, and anything using BigQuery-specific syntax such as EXCEPT in a SELECT or table wildcards. Budget the effort by counting distinct query patterns, not total queries.

How does the BigQuery to Snowflake sync work?

Is there a prebuilt BigQuery connector for Snowflake?

Yes. This BigQuery to Snowflake connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.

How much does the BigQuery Snowflake integration cost?

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

How often can Adapters sync BigQuery to Snowflake?

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

Do I need to write code to connect BigQuery and Snowflake?

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. BigQuery NUMERIC casts to Snowflake NUMBER(38,9) and BIGNUMERIC to NUMBER at its declared precision, STRUCT and ARRAY RECORD columns land as VARIANT so nested payloads survive the trip, TIMESTAMP stays UTC so no hour shifts on the way across, and STRING maps to VARCHAR. Incremental runs use an updated-at watermark per table, target tables cluster on the load date, and writes MERGE on the primary key so you can re-run a window during parallel validation without duplicating a single row.

More pairs from the API connector library

Browse the full api connector library, or request a pair you do not see.

BigQuery and Snowflake, finally in agreement

Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.

Try the live demo

No credit card required.