Migrate MySQL to MongoDB
Beta — live-tested pathMigrating from MySQL (the world's most deployed open-source relational database) to MongoDB (the leading document database) means every table, column type, key, index and row has to survive two engines' different opinions about data. This is a cross-model migration — rows and relations are preserved as structured documents — and the conversion rules are explicit, not guessed. DBShifts converts the schema with deterministic rules, transfers data in parallel batches, and validates the result with per-table row counts and type-aware checksums.
Free tier · no credit card
MySQL vs MongoDB
MySQL
the world's most deployed open-source relational database.
MongoDB
the leading document database.
How the migration works
Connect
Point DBShifts at your source and target. Credentials stay encrypted; SSH tunnels supported for private databases.
Analyze
Automatic schema introspection produces a migration plan: what converts automatically, what migrates with warnings, what needs human review.
Migrate
Schema is created on the target, data transfers in parallel batches with constraints deferred, indexes rebuilt after load.
Validate
Per-table row counts, type-aware checksums on both sides, FK integrity — plus a fidelity report listing anything lossy.
A table-per-collection copy is rarely what you want
The straightforward conversion turns each table into a collection and each row into a document, which produces a working MongoDB database that is still shaped like a relational one. Joins that the database used to perform now have to happen in the application or through aggregation pipelines, and the result is usually slower and more complex than the source.
The value of the move comes from embedding: an order and its line items as one document, read in a single operation. That is a modelling decision about your specific data, not something a converter should make for you, so the sensible sequence is a faithful copy first, then reshape deliberately, with the copy kept as a checkable baseline.
Types that change meaning on the way in
MySQL DECIMAL should become Decimal128, not double. A converter that maps DECIMAL to a JavaScript double introduces binary rounding into exact values, and it will not be noticed until totals disagree by fractions of a cent.
TINYINT(1) is MySQL's boolean, and it should become a real boolean rather than the integer 0 or 1, otherwise every query written against MongoDB has to know that 1 means true. Plain TINYINT is a small integer and must not get the same treatment.
DATETIME has no timezone in MySQL, while MongoDB stores dates as UTC milliseconds since the epoch. The conversion has to assume a timezone for naive values, and assuming the wrong one shifts every timestamp by a fixed offset that is very hard to spot after the fact.
What you give up, stated plainly
There are no foreign keys. Referential integrity becomes the application's responsibility, and existing orphan rows migrate silently because nothing rejects them.
Transactions exist across documents in modern MongoDB, but they are not the default programming model and carry different performance characteristics from a relational transaction. Code that relied on multi-statement transactions needs review rather than translation.
There is no schema, so nothing prevents a later write from adding a field with a different type in the same collection. Schema validation rules can be added, and on a migrated database they are worth adding immediately, while you still know exactly what the shape should be.
MySQL → MongoDB conversion notes
Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.
- TINYINT(1) is treated as a boolean; plain TINYINT stays numeric — converting both blindly corrupts ratings and counters.
- UNSIGNED integers are widened on targets without unsigned types, so values above the signed range survive.
- ENUM and SET columns are converted with their value lists preserved (native enums, CHECK constraints, or arrays depending on the target).
- TIME columns are durations (-838h..838h) at the driver level — DBShifts converts them per target instead of failing the batch.
- Zero dates (0000-00-00) are normalized deterministically and reported, never silently dropped.
- Rows become flat documents; write errors surface loudly instead of being swallowed by duplicate-tolerance settings.
- Integers beyond BSON's 8-byte range (e.g. Oracle NUMBER) become Decimal128 to stay exact.
- Dates are stored as native BSON dates (UTC instants).
Frequently asked questions
Is MySQL to MongoDB migration production-ready in DBShifts?
MySQL to MongoDB is a live-verified beta pair: it passed the same certification suite as every other pair — a real migration with edge-case data validated by row counts and checksums — and ships with a post-migration fidelity report you can audit before cutover.
How does DBShifts verify the MySQL to MongoDB migration was correct?
Three layers: per-table row counts on both sides, an order-independent type-aware checksum of row data (canonicalized so engine representation differences don't false-alarm), and FK integrity checks on the target. Rows that fail to insert are quarantined with the exact error — never silently dropped — and can be fixed and retried from the UI.
What happens to MySQL types that MongoDB doesn't have?
They convert by deterministic rules with a recorded decision: a native equivalent where one exists, a portable fallback (TEXT/JSON/DECIMAL) where one doesn't. Every lossy conversion appears in the migration plan before you run and in the fidelity report after. You can override any mapping per column.
Can I keep MySQL and MongoDB in sync after the initial migration?
Yes. DBShifts supports incremental sync (UPSERT-based delta transfers on a sync key) and, for supported sources, real-time change data capture so the target stays current until you cut over.
Do I need to write any SQL or scripts for MySQL to MongoDB?
No. Connect both databases, review the generated migration plan (what's automatic, what migrates with warnings, what needs manual review — typically triggers and stored procedures), and run. Procedural code is transpiled best-effort and queued for human review rather than auto-applied.
What's the hardest part of moving MySQL to MongoDB?
The data model itself differs (sql → nosql), so rows and relations are restructured into documents with explicit type rules. DBShifts surfaces every inference and lossy conversion in the migration plan before you run, so nothing is guessed silently.
Go deeper
Related migration paths
Ready to move MySQL to MongoDB?
Set up in under two minutes. Validation and rollback included.
Start Free Migration