Does Google have a native MySQL to BigQuery connector?

Yes. BigQuery Data Transfer Service has a MySQL connector for scheduled transfers, with incremental transfers in Preview that cannot sync deletes. Datastream replicates changes from the binary log or with GTIDs and is priced per GiB processed. For Cloud SQL, federated queries can also read MySQL without copying data.

Are MySQL syncs to BigQuery incremental?

They can be. Weld's MySQL connector runs full syncs by default, and you switch tables to merge incremental syncs, which need a primary key and a cursor such as updated_at, or append syncs, which need only a cursor.

Does Weld support MySQL CDC into BigQuery?

Yes. Weld reads row-based events from the binary log and applies inserts, updates and deletes to BigQuery. It needs log_bin on, binlog_format ROW, binlog_row_image FULL, a unique server_id, and either a weld_watermark table or GTIDs.

How are deleted rows handled?

Merge and append syncs do not capture deletes. A full sync at midnight removes deleted rows once a day, and CDC propagates deletes as they happen.

Does it work with Amazon RDS and Aurora MySQL?

Yes. For CDC on RDS or Aurora, set the binlog settings from Weld's MySQL CDC guide in a custom parameter group, restart the instance, and set binlog retention hours with mysql.rds_set_configuration.

Can Weld keep a history of changes to MySQL rows?

Not for this connector. History tables are not available for MySQL sources in Weld, so each BigQuery table holds the current state of the source table.

MySQL to BigQuery

Copy your MySQL tables into BigQuery and keep them current, with incremental syncs on a cursor column or CDC that reads the binary log and carries deletes. Weld connects directly or through an SSH tunnel, and you choose per table how it syncs.

Start for free View setup guide

4.8 on G2

Source

Weld

Warehouse

Checked against Weld and vendor docs on 10 October 2026

Weld · New sync

SourceMySQLConnected

Tables to sync

Your own tables, picked when you set up the sync.

Extract
Load
Keep in sync

DestinationGoogle BigQueryReady

mysql dataset

mysql.Synced
mysql.Syncing
mysql.Synced
mysql.Synced

Trusted by data and AI teams

Options

Four ways to get MySQL data into BigQuery

Google offers a scheduled transfer, a CDC service and federated queries for Cloud SQL. They fit well when MySQL already runs in Google Cloud. The deciding questions are deletes, freshness and whether MySQL is one source among many.

BigQuery Data Transfer Service

Best for: Scheduled batch copies inside Google Cloud
Effort: Low to medium: a transfer config, plus a network attachment if the database has no public IP
Freshness: Hourly, daily or custom schedules, or on demand
Good to know: Full transfers reload every run. Incremental transfers are in Preview, need a TIMESTAMP watermark column and cannot sync deletes. Billed by slot-hours as a GA connector.

Datastream

Best for: Binlog or GTID based CDC into BigQuery
Effort: Medium: binlog settings, a connection profile and a stream
Freshness: Continuous, merged into BigQuery on a staleness setting you choose
Good to know: Supports MySQL 5.6 to 8.4 and InnoDB tables only. Priced per GiB processed, with the first 500 GB of backfill each month free. Streams are limited to 10,000 tables.

Federated queries (Cloud SQL only)

Best for: Occasional joins against a Cloud SQL database
Effort: Low: a BigQuery connection and EXTERNAL_QUERY
Freshness: Live at query time
Good to know: Queries Cloud SQL for MySQL without copying data, so every query runs against your database. Users on the caching_sha2_password plugin are not supported.

Weld

Best for: MySQL alongside your other sources in one pipeline
Effort: Low: connect, pick tables, choose a sync mode per table
Freshness: CDC in near real time, or incremental and full syncs on your schedule
Good to know: Merge syncs need a primary key and a cursor such as updated_at; append syncs need only a cursor. CDC reads the binlog and propagates deletes. Columns can be removed or hashed.

How it works

How to sync MySQL to Google BigQuery with Weld.
In the app, with the API or an agent.

Setup guide API guide MCP docs

Weld · Data warehouse

Data warehouseGoogle BigQueryConnected

Data locationChosen when you connect

CredentialsService account or key, stored encrypted

Data

What lands in Google BigQuery
From MySQL to Google BigQuery.

Weld does not impose a schema on a database source: what lands in BigQuery is the tables you select, with the columns you keep.

Your selected tables
One BigQuery table per MySQL table you pick, under the destination name you set. Removed columns are left out and hashed columns arrive hashed.
_weld_synced
A timestamp Weld adds to every row with the time it was last synced. Use it to check freshness without touching your own columns.
weld_watermark
Not a destination table: a small table you create in MySQL for CDC, where Weld stores high watermarks during incremental snapshots. Skip it if you enable GTIDs instead.

Example query

Daily new rows in a replicated table.
In Google BigQuery SQL.

Runs in BigQuery against a dataset named mysql. Illustrative: replace orders with one of your tables and created_at with its creation timestamp column.

Google BigQuery · query

1select2  date(o.created_at) as day,3  count(*) as new_rows,4  max(o._weld_synced) as last_synced_at5from mysql.orders as o6where date(o.created_at) >= date_sub(current_date(), interval 30 day)7group by day8order by day desc

Weld MCP server

Ask your agent.
It queries Google BigQuery for you.

Connect Claude, Cursor, ChatGPT or your own agent to Weld over MCP. It reads the MySQL context, finds the tables it needs and runs the query in Google BigQuery.

Set up the MCP server

Claude CodeOpus 5

ConnectedWeld MCP

Which MySQL tables do we have in Google BigQuery, and which is the largest?

Looking up what Weld has synced from MySQL.

●weld·search_available_references

⎿raw.mysql.*

tables, columns and freshness

●weld·get_reference_schema

⎿columns, types and nullability

●weld·run_query

⎿select count(*) from {{raw.mysql.…}}

submitted

●weld·get_query_status

⎿DONE

●weld·get_query_result

⎿rows returned

✓Answered from MySQL data in Google BigQuery

>Ask about your MySQL dataMCP

Under the hood

Things to know.
Before you sync MySQL.

Tables start on full syncs: Weld's MySQL connector runs full syncs by default. Switch large tables to incremental: merge needs a primary key and a cursor timestamp, ideally updated_at; append needs only a cursor but does not pick up updates to existing rows.
Incremental syncs do not see deletes: Neither merge nor append captures deleted rows. Use a full sync at midnight for tables with frequent deletes, or CDC, which reads deletes from the binlog.
Binlog retention is your recovery window: CDC resumes where it left off, so binlogs must outlive any outage. Weld recommends at least three days and seven as a default, refuses CDC below six hours, and on RDS the maximum retention is seven days.
Only keyed tables can use CDC: Each CDC table needs a primary key or unique index. Weld reads this from INFORMATION_SCHEMA, which is filtered by privileges, so a keyed table the Weld user cannot see will not be offered.
Server timezones must be IANA names: If the server uses a legacy timezone name outside the IANA database, CDC may misread timestamps. Set an IANA timezone on the server or in the connector settings.

Sources: Weld MySQL connector docs · Weld MySQL CDC docs · Weld BigQuery setup guide · Weld managed fields · Google Cloud: Load MySQL data into BigQuery · Google Cloud: BigQuery pricing (Data Transfer Service) · Google Cloud: Datastream MySQL source · Google Cloud: Datastream pricing · Google Cloud: Cloud SQL federated queries