MySQL to BigQuery sync that lands MySQL tables in BigQuery incrementally

The MySQL to BigQuery connector from Adapters syncs MySQL tables into BigQuery on an incremental schedule, converting MySQL types to BigQuery types and merging on the primary key so your dashboards read warehouse tables instead of hitting the production database. 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 MySQL to BigQuery by hand costs you

Dashboards pointed straight at production MySQL add load to the database that also takes customer orders.
BigQuery bills by bytes scanned, so an unpartitioned copy of a large MySQL table turns a cheap dashboard into a recurring line item.
Reloading the whole table nightly is simple until the table is 400 million rows and the load runs into business hours.

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 / MYSQL

Output / BIGQUERY

orders.id

customers.email

customers.full_name

customers.name

orders.total_amount

orders.updated_at

orders.created_at

orders.status

Transforms included

Incremental runs use a MySQL updated_at watermark so only changed rows load; DECIMAL maps to BigQuery NUMERIC at its declared scale (and BIGNUMERIC past 38 digits), TINYINT(1) becomes BOOL, DATETIME and TIMESTAMP normalize to BigQuery TIMESTAMP in UTC while true wall-clock columns can stay DATETIME, JSON columns land as JSON, destination tables are partitioned on the load date so queries prune bytes scanned, and loads MERGE on the primary key so replays never duplicate.

MySQL to BigQuery: binlog requirements, the load job quota, and the types that need a decision

Two things decide whether this lane is boring or painful: whether MySQL is configured so a replication tool can read the binary log, and whether your loader respects the BigQuery load job quota. Below: the exact MySQL settings change data capture needs, the quotas that break naive pipelines, the type conversions worth setting by hand, and when a watermark is the better answer. Google Cloud documentation read 15 August 2026, MySQL replication requirements verified 4 August 2026.

What MySQL must be configured for before CDC works

Log-based replication reads the binary log, and the defaults are usually wrong for it. You need binlog_format = ROW, because the STATEMENT format records the SQL rather than the resulting row values and cannot be replayed reliably into a warehouse. You also need binlog_row_image = FULL, so that every column arrives on an update rather than only the changed ones, which is what lets the pipeline build a complete row. GTID-based replication is supported on MySQL 5.7 and later and makes recovery after a failover far simpler. Retention matters too: if binary logs expire faster than your pipeline can fall behind and catch up, an outage over a long weekend means a full resync rather than a resume. On Amazon RDS and Cloud SQL these are parameter group settings, and some require a restart.

The BigQuery quotas that decide the loading strategy

BigQuery allows 1,500 load jobs per table per day and 100,000 per project per day, and failed jobs count toward both. A loader that submits one job per file or per small batch will exhaust a busy table's allowance well before the day is out. A single job also caps at 15 TB of input and fails after 6 hours, which is what a full history dump of a large table hits, so split the first backfill by primary key range or by date. Batch loads themselves are free of charge because they run on a shared slot pool; you pay for storage and for the queries afterwards. When frequent updates keep pushing you past the load job limits, Google's own guidance is to stream through the Storage Write API instead, which does not consume the load job quota.

Backfill limits worth checking before you start

Managed replication services impose their own shape on the initial load. Datastream supports MySQL among its sources and writes to BigQuery, Cloud Storage or Apache Iceberg, with a limit of roughly 10,000 tables per stream and a cap of 20 MB per event for BigQuery destinations, which matters for tables carrying large BLOB or TEXT columns. Backfilling very large tables, above roughly 500 million rows, requires a unique non-null index the service can use to chunk the read, so a table without a primary key needs one added or needs its history loaded another way. Check this against your largest tables before committing to an approach, because discovering it midway through a migration is expensive.

The type conversions that need a deliberate decision

MySQL DECIMAL maps to BigQuery NUMERIC at its declared scale, and to BIGNUMERIC beyond 38 digits of precision. Do not let schema autodetect handle money columns: it samples the file, so an amount column whose first rows are whole numbers is detected as INTEGER and the cents are silently gone. TINYINT(1) is MySQL's boolean and should become BOOL, not an integer, or every downstream filter reads awkwardly. The timestamp distinction is the one worth thinking about: MySQL TIMESTAMP is stored in UTC and converted on read, while DATETIME is a wall clock value with no zone at all. Normalize TIMESTAMP columns to BigQuery TIMESTAMP in UTC, and only keep DATETIME where the value genuinely is a wall clock reading such as a store opening time. MySQL JSON columns land in the native BigQuery JSON type. Finally, BigQuery field names allow only letters, numbers and underscores and cannot start with a digit, so rename offending columns in the load schema rather than letting the job fail.

Partition, cluster and MERGE so reruns are safe

Partition the destination on the load date or on a business event timestamp, and cluster on the columns you filter by. BigQuery bills by bytes scanned, so an unpartitioned table means every dashboard query pays for the full history, and retrofitting the change means creating a new table and repointing everything that reads the old one. On the write side, land each run into a staging table and MERGE into the target on the primary key rather than appending. That single choice is what makes a rerun safe: a failed sync becomes a non-event you can simply repeat, instead of an incident that duplicated rows in a revenue report.

Watermark or CDC, and how Adapters fits

A watermark query filtering on updated_at needs no binlog access, no parameter changes and no restart, which on a managed MySQL instance you do not fully control is a real advantage. It misses hard deletes and any row updated by a process that does not touch the timestamp. CDC catches both and costs you the configuration above plus lag monitoring. Use a watermark when the table is append-mostly and a missed delete does not change a reported number, use CDC when deletes matter or freshness is measured in minutes, and reload small lookup tables in full. Adapters runs scheduled incremental syncs with visual field mapping, explicit type casting you can review before the first run, batched loads that stay well inside the job quota, MERGE on the key, retries, alerting on the run that did not happen, and per-record error logs, on a flat monthly price from $49. It is not the right pick if you need sub-second replication, where Datastream is the correct answer, or if the project needs dozens of additional SaaS connectors.

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 MySQL and BigQuery 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 replicating MySQL into BigQuery covers the field-by-field detail, the failure cases, and what changes at volume.

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

MySQL to BigQuery sync: common questions

How do I connect MySQL to BigQuery?

Two realistic routes. Google Datastream reads the MySQL binary log and streams changes into BigQuery, which suits low-latency replication and requires binlog access on the source. A scheduled incremental sync reads an indexed watermark column and merges into partitioned BigQuery tables, which needs no binlog and no replication privileges. Pick by whether you need seconds or minutes.

What does Datastream need on the MySQL source?

Binary logging in ROW format with binlog_row_image set to FULL, binlog_row_value_options empty on MySQL 8.0 and above, and no binlog transaction compression. Datastream supports MySQL 5.6, 5.7, 8.0 and 8.4, uses GTID on 5.7 and later, caps a stream at 10,000 tables, and needs a unique non-null index to backfill any table above 500 million rows.

How do I migrate MySQL to BigQuery without CDC?

Run an incremental sync on an indexed updated_at or auto-increment column and MERGE into a partitioned BigQuery table on the primary key. It costs you the ability to see hard deletes, which is the honest trade: if rows are only ever soft-deleted, this is simpler, cheaper and has no replication slot or binlog retention to monitor.

Which BigQuery types should MySQL columns map to?

DECIMAL becomes NUMERIC, never FLOAT64, or currency drifts. TINYINT(1) is a boolean in practice and should land as BOOL. DATETIME has no zone so it maps to DATETIME, while TIMESTAMP maps to TIMESTAMP. TEXT and JSON columns go to STRING or JSON. Partition on the load or modified date and cluster on the key you filter by most.

How does the MySQL to BigQuery sync work?

Is there a prebuilt MySQL connector for BigQuery?

Yes. This MySQL to BigQuery 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 MySQL BigQuery 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 MySQL to BigQuery?

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 MySQL and BigQuery?

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental runs use a MySQL updated_at watermark so only changed rows load; DECIMAL maps to BigQuery NUMERIC at its declared scale (and BIGNUMERIC past 38 digits), TINYINT(1) becomes BOOL, DATETIME and TIMESTAMP normalize to BigQuery TIMESTAMP in UTC while true wall-clock columns can stay DATETIME, JSON columns land as JSON, destination tables are partitioned on the load date so queries prune bytes scanned, and loads MERGE on the primary key so replays never duplicate.

More pairs from the API connector library

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

MySQL and BigQuery, 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.