Question 1

What do I need to enable on MySQL to sync to BigQuery?

Accepted Answer

Grants for SELECT, REPLICATION CLIENT and REPLICATION SLAVE, and server settings with log_bin on, binlog_format set to ROW and binlog_row_image set to FULL. On MySQL 8.0.1 and later, binlog_row_metadata should be FULL too. GTID with enforce_gtid_consistency is recommended, with position based replication as the fallback. Keep binary logs for at least twenty four hours so a paused sync can resume instead of needing a full reload.

Question 2

What happens to MySQL tables without a primary key?

Accepted Answer

They still sync, but they are written differently, and this is specific to how BigQuery handles them. Matching uses the unique fields configured on the sync rather than any key BigQuery declares, so with none configured there is no merge to perform. A complete snapshot rebuilds or replaces the table instead. There is an option to truncate the destination table rather than drop and recreate it, which preserves the table and its schema. A retain style refetch against an unkeyed table is skipped rather than doubling every row.

Question 3

Can I read from a MySQL replica?

Accepted Answer

Yes. A replica is not required, but pointing the connection at one is supported as long as it exposes readable binary logs and has the privileges and settings above. That is the usual arrangement when the primary is busy or when policy keeps outside systems away from it. Tables still need a primary key to use change capture, which is normally the thing that decides whether a given table can stream or has to fall back.

Question 4

Do MySQL deletes reach BigQuery?

Accepted Answer

Yes, with change capture on and a primary key present. The merge marks the row with a deleted at timestamp by default, so it stays visible to anything counting what has gone, and the propagate hard deletes option removes those rows for real afterwards. One constraint to know: hard deletes need the Polytomic timestamp columns left enabled, because the delete keys off them. Tracking field syncs do not carry deletes at all.

Question 5

Why replicate MySQL into BigQuery?

Accepted Answer

Because a database tuned for serving your product is the wrong place to run analysis. Long aggregations compete with live traffic, and the context you actually want, CRM records or billing history, was never in MySQL. ETL into a data warehouse shifts that work elsewhere and puts application tables beside everything else. BigQuery suits this particularly well because there is no staging storage to run, so the operational overhead is close to nothing.

Sync MySQL to BigQuery

Sync MySQL to BigQuery with Polytomic

Deletes come from the log

Keys decide the write path

Backfill then follow

Or sync BigQuery to MySQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect MySQL in Polytomic

Connect BigQuery in Polytomic

Create a sync between MySQL and BigQuery

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect MySQL with BigQuery?