MongoDB to MySQL: How to Move Your Data
Replicate MongoDB collections into MySQL tables with Airbyte's CDC connectors. Prerequisites, schema modes, nested document handling, and volume limits.
Moving data from MongoDB to MySQL means translating flexible, nested documents into fixed relational rows, then doing it again on a schedule without adding load to the cluster serving your application. A one-off mongoexport handles the first copy. It does not handle the second one, and it never captures deletes.
This guide covers the managed path: replicating MongoDB collections into MySQL tables with Airbyte, using change data capture. It also covers the prerequisites that stop the pipeline at setup rather than at runtime, because on this source there are several and they are strict.
MongoDB to MySQL at a glance:
Why move data from MongoDB to MySQL?
Two situations account for most of these pipelines.
The first is giving SQL tools something to read. MongoDB is serving the application well, and the reporting layer, the BI tool or an internal admin panel all expect relational tables. Replicating collections into MySQL gives them joins and a stable schema without adding read load to the operational cluster.
The second is a genuine migration. The application has outgrown a schemaless store and wants foreign keys and multi-table transactions. Here the pipeline runs alongside the old system during cutover, keeping MySQL current until traffic switches, and the schema decisions below stop being a convenience and start being the design of your new database.
What do you need before you start?
The MongoDB source has hard prerequisites, and most failed setups trace back to one of them:
A replica set. Airbyte reads changes from MongoDB change streams, which only exist on a replica set. A standalone mongod will not work. On Atlas this means a dedicated M10 tier or above, since shared tiers can fail during connection setup.
TLS and a user with readAnyDatabase. Encryption is required by the connector and is on by default for Atlas clusters. Since connector version 2.0.0 a single source can sync collections across multiple databases, and that expanded access needs the readAnyDatabase privilege, without which the connection fails with an authorization error. The MongoDB source docs walk through both Atlas and self-hosted.
A consistent _id type. Every document in a collection must use the same data type for _id. Mixed types are unsupported. Views, capped collections, clustered collections and empty collections are also excluded.
A MySQL user with write access. On the destination side, a database and a user able to create and write tables in the target schema. Airbyte adds its own metadata columns to each table alongside your data.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on both databases before you begin.
How do you build a MongoDB to MySQL pipeline in Airbyte?
Step 1: Create a read-only MongoDB user
In Atlas, add a database user under Security and then Database Access with password authentication, give it the built-in read any database role, add the readAnyDatabase specific privilege, and restrict it to the clusters you intend to replicate. Self-hosted, create the equivalent user in mongosh and enable authorization in your config.
Step 2: Configure the MongoDB source
Click Sources in the left navigation, then New Source, and select MongoDB, following adding a source. Supply the cluster type, connection string, database names and the credentials from step 1. One advanced setting deserves attention: because collections are schemaless, Airbyte samples documents to infer fields, 10,000 by default and configurable between 1,000 and 100,000. That discovery runs sample aggregations against every collection in parallel, which can put real pressure on a busy production cluster, so consider pointing it at a secondary.
Step 3: Configure the MySQL destination
Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. If this is a migration, decide now whether the application can tolerate Airbyte's metadata columns in the tables it will read, or whether you will expose views that exclude them.
Step 4: Choose sync modes and run
Click Connections, then New connection, select your collections, and pick a sync mode per stream. Incremental with CDC keeps MySQL current and propagates deletes. Full refresh re-reads a collection end to end and is checkpointed, so a network failure resumes rather than restarts. Set a replication frequency, save, and trigger the first sync.
How do nested MongoDB documents land in MySQL?
This is the decision that shapes all your downstream SQL, and it is made in the source configuration rather than the destination.
In schema-enforced mode, the default, Airbyte samples documents, builds a field list, and lets you deselect fields you do not need. Top-level fields become typed MySQL columns. When a field's structure disagrees with the inferred schema, say a single object where an array was expected, the connector wraps it rather than writing NULL. That handling is meant for occasional inconsistencies, not for fields that change type routinely.
In schemaless mode, every document produces a record with just _id and a data object holding the full document. Nothing is dropped and nothing is rejected, but the unpacking happens in MySQL, using its JSON functions or a downstream modelling layer. Pick enforced mode when collections are stable enough to model, and schemaless when they genuinely vary.
When is MySQL the wrong destination?
MySQL is a relational database, not a warehouse. If your MongoDB estate runs to tens of gigabytes or more and the goal is analytics rather than an application migration, you will hit write throughput and memory limits long before you hit anything interesting analytically. Route the same source to a warehouse destination instead; the connector setup is identical and only the destination changes.
Two specific limits are worth planning around. MySQL caps identifiers at 64 characters, so deeply nested documents flattened into long column names can collide and fail the sync. Shortening field names at the source, or choosing schemaless mode, both avoid it.
And during CDC, MongoDB's 16MB document limit can surface as a BSONObjectTooLarge error when change events carry large documents. The MongoDB troubleshooting guide covers the fix. If your collections hold large embedded arrays, check for this before you rely on the pipeline.
Frequently asked questions
Do I need a MongoDB replica set?
Yes. The connector reads from change streams, which only exist on a replica set. Atlas clusters on the M10 dedicated tier or above qualify, and shared tiers may fail at setup.
Are deletes propagated to MySQL?
Yes, when the stream uses incremental CDC. Full refresh mode re-reads the collection instead and does not track individual deletions.
Why did my connection fail with an authorization error?
Most likely the missing readAnyDatabase privilege, which the connector needs because a single source can sync collections across multiple databases.
My sync fails with BSONObjectTooLarge. What now?
A change event is carrying a document near MongoDB's 16MB limit. The MongoDB troubleshooting guide covers the fix; collections with large embedded arrays are the usual cause.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven, from creating the source through to scheduling the connection. If you would rather manage pipelines as infrastructure, the same source, destination and connection can be provisioned from configuration files instead.
Get your MongoDB data into MySQL
You can have this connection running before the end of the day, with CDC, schema handling and deletes covered. Confirm the replica set and the readAnyDatabase privilege first, decide between enforced and schemaless mode deliberately, and watch the identifier length limit if your documents nest deeply.
Airbyte's connector catalog includes 600+ pre-built connectors, so the same MongoDB source can fan out to a warehouse later without rebuilding anything. For the equivalent pipeline into a relational destination with a slightly different type model, see MongoDB to PostgreSQL, and for MySQL as a source rather than a destination, MySQL to Snowflake.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.