Skip to main content
MySQL · binlog CDC

Replicate MySQL to your cloud warehouse.

Describe the sync in plain English, approve it once, and rsync.ai streams every INSERT, UPDATE, and DELETE from MySQL into Snowflake, BigQuery, Databricks, or Postgres — read straight from the binary log, no polling and no missed deletes.

Real-time binlog CDCYou approve every syncNo per-row pricing
Connect MySQL free →See how a sync runs
Reads the MySQL binlog — no polling You approve before anything moves
Destinations

Send MySQL data where your team already works.

Pick where it lands. rsync.ai maps MySQL types automatically and builds the pipeline — you approve the plan before anything moves.

Cloud warehouse

Land typed, query-ready tables for BI and analytics — incremental after the first snapshot.

BigQueryDatabricksSnowflakeRedshift

Another database

Replicate MySQL into Postgres — or into a fresh MySQL for a migration — with automatic type mapping and real-time CDC.

PostgreSQLMySQL

Storage, lake & sheets

Write Parquet, JSON, or CSV to object storage for your lake, or push query results to a live spreadsheet.

Amazon S3GCSAzure BlobGoogle Sheets
What syncs

Every MySQL object, mapped to typed columns.

Tables
Views
Primary keys
Binlog CDC · ROW
Snapshot + incremental
TINYINT(1) → BOOLEAN
DATETIME → TIMESTAMP
ENUM → TEXT
How it works

Four steps. You are in the loop for each one.

01

Describe it

Name the tables to replicate in plain English — no SQL, no binlog wrangling, no connector config.

02

Review the plan

rsync.ai discovers the schema, maps MySQL types to the destination, and flags any PII before a row moves.

03

Approve

Nothing runs until you say yes. When the schema changes, the pipeline pauses for the same review.

04

Stream

rsync.ai reads the binary log and keeps the destination live within seconds; a failed run resumes from its last binlog position.

Compare

Why teams move MySQL this way.

What you care aboutmysqldump / cronDebezium + KafkaPer-row ETLrsync.ai
Set up without an engineerNoNoRarelyPlain English
Real-time binlog CDCBatch dumpsYesVariesYes
Types mapped automaticallyBy handYou build itSometimesAutomatic
You approve before it runsn/aNoNoYes
Cost as volume growsYour timeInfra + opsRises per rowPer GB, not per row

Straight about status: the MySQL source and its Postgres, BigQuery, Databricks, storage, and Google Sheets destinations are live in production. Snowflake and Redshift are in preview. Self-hosting in your own VPC is coming soon — today rsync.ai runs as a managed cloud.

FAQ

MySQL replication — common questions

How fresh is the data?
You choose the schedule, from a few times a day down to near real time. rsync.ai reads MySQL's binary log (binlog CDC) in ROW format, so it captures every INSERT, UPDATE, and DELETE — including the deletes that polling misses — and writes only the rows that changed. A failed run resumes from its last committed binlog position instead of starting over.
Does MySQL CDC work on Amazon RDS, Aurora, Cloud SQL, and PlanetScale?
Yes. On RDS and Aurora, enable automated backups and set binlog_format=ROW in the parameter group. On Google Cloud SQL, enable point-in-time recovery (which turns on binary logging) and set binlog retention. On Azure Database for MySQL, use the log_bin and binlog_expire_logs_seconds server parameters. PlanetScale disables raw binlog access by design, so rsync.ai falls back to its native Connect API (CDC-over-HTTP) — you still get row-level change events. Both GTID and file+position replication are supported.
Should I use GTID or file+position replication?
Use GTID if your MySQL supports it (5.6+ with gtid_mode=ON). GTID gives each transaction a globally unique identifier, so rsync.ai resumes from an exact transaction boundary after a failover or primary switchover — no manual position bookkeeping. File+position works fine for single-primary setups but requires recording the exact binlog file and offset at snapshot time. rsync.ai supports both; GTID is the recommended default.
Do I need to write SQL or configure a connector?
No. Describe the sync in plain English. rsync.ai discovers the schema, maps MySQL types to the destination — TINYINT(1)→BOOLEAN, ENUM→TEXT, UNSIGNED INT→BIGINT, and more — flags PII, and shows you the plan. Nothing runs until you approve it, and you can mask or hash sensitive columns (SHA-256) before they ever leave your network.
How are you priced?
On data volume (GB moved), not per row or Monthly Active Rows — so your bill tracks bytes moved, not row counts. Each plan includes a GB allowance, and pipelines pause at the limit rather than silently running up charges; beyond the allowance it's a flat $3/GB.
Who controls what moves?
You do. Every sync waits for your approval, PII is flagged before it lands, and later schema changes pause for review. Self-hosting entirely in your own VPC is coming soon for teams that need data to never leave their network.

Put your MySQL data in the warehouse.

Connect your database free and send your first live sync to BigQuery or Databricks today.

Connect MySQL free →See how it works
Live on rsync.ai Cloud today · self-hosting coming soon