Key takeaways
- General availability. MariaDB Migrator is out of beta and hardened across more source and target combinations.
- More Sources and Targets. This release offers a wider matrix of source (MySQL) and target (MariaDB) versions.
- Runs on its own. A bash launcher, a YAML file, and four modes. No assistant, no agent, and nothing installed on your core database server.
- A faster parallel engine. mariadb-mtk now parallelises within a single large table as well as across tables, and moves rows in-session with no intermediate dump file.
- Conversational migrations, if you want them. For teams that want an AI front end, mariadb-shell - in pre-release now (Planned for general availability in Q4 2026) can expose the migrator through its MariaDB MCP server, so Claude or any MCP-capable assistant can assess, plan, and run a migration as a conversation instead of a command sequence.
In July we introduced MariaDB Migrator as a beta: four migration modes, a read-only Assess and Plan phase, and a single YAML file driving the whole thing.
Michael Aglietti then walked through three failures even a careful migration can miss.
Today MariaDB Migrator is generally available.
A Video Walkthrough of the MySQL to MariaDB Migrator
If you’d like to watch a video on what’s new in the MariaDB Migrator, check this out:
What Migration Modes Are Supported?
Every migration from MySQL to MariaDB begins with Assess and Plan. It reads your source, reports what it finds, and produces a plan, without writing anything anywhere. When you are ready to move data, four modes map to different operational constraints:
| Migration Mode | Best For | Mechanism |
|---|---|---|
| Serial Streaming Copy | Smaller databases | Streams sequentially using mariadb-dump | mariadb |
| Parallel Streaming Copy | Large datasets | Parallel worker sessions via mariadb-mtk |
| Offline Copy | Air-gapped environments | Decouples dump and load phases |
| Replication | Mission-critical cutovers | Keeps target in sync via binlog |
What GA adds is the confidence that comes from running these against a much wider matrix of source and target versions, a faster engine underneath the parallel mode, and one genuinely new way to use the tool.
Inside Parallel Streaming Copy: What Got Faster?
Our focus for this development cycle was to add restartable loads and parallel loading of very large tables, and that is what shipped.
mariadb-mtk is the engine behind Parallel Streaming Copy. Rows move from source to target in-session: the engine holds open connections on both sides and streams result sets straight into the target. On a large database, this removes both the disk footprint and an entire I/O round trip from the critical path.
Two levels of parallelism now work together:
- Across tables (inter-table). Several tables transfer concurrently, each in its own worker session. The session count is yours to set, and it is why a run log shows tables starting and finishing interleaved rather than one after another.
- Within a table (intra-table). This is the new capability. A table past a row-count threshold is split into chunks, and its chunks are transferred concurrently, so a single dominant table no longer serializes the tail of your migration.
That combination is what changes the shape of a long run. Inter-table parallelism alone hits a wall the moment one table is bigger than all the others put together. Chunking it removes the wall.
Two things worth knowing before you plan around this. Against a MySQL source, only tables with an auto-increment column can be chunked, and the large-table threshold is expressed in rows rather than megabytes; a large table without an auto-increment key still transfers in a single session.
MariaDB Migrator’s restart behaviour retries transient failures, timeouts, and lost connections within a run, immediately and then with progressive backoff on reconnect. It is self-healing during a transfer, not a resume point between separate invocations.
How to Drive a MySQL to MariaDB Migration as a Conversation
MariaDB Migrator is now exposed as tools conversationally through the MariaDB MCP server in the mariadb-shell. An MCP-capable assistant can see the migrator alongside the server’s database inspection tools, which means the migration workflow (set the configuration, plan, run, resume) becomes something you ask for rather than something you assemble.
In practice it looks like this. You point the assistant at your two connections and describe the constraint rather than the mechanism:
Migrate the shop schema from the MySQL 8.4 source to the MariaDB target.
I have at most a 20-minute maintenance window.
The assistant reads the source schema, recognizes that a short window points to replication mode, checks the source for JSON columns, finds two, and comes back with the reason that mode is closed to you and which of the offline modes fits the data volume instead. That is the tool’s own preflight logic, arriving as an answer to a question you asked in English, before you have written any configuration at all.
The plugin ships skill files alongside the tools. Those files carry the operating contract an assistant cannot infer from tool signatures on their own: which mode suits which constraint, which modes gate on what, where the parallel engine’s restart behaviour applies within a run and where it does not.
What the MariaDB Migrator Assistant Does and Does Not Do
The assistant orchestrates. It inspects the source, proposes a mode and explains the tradeoff, writes the configuration, runs the phases, reads the resulting report, and tells you what failed and why.
That last part matters more than it sounds, because a migration report is a dense artifact, and having something read back to you in context is valuable.
The assistant does not translate your DDL. Schema conversion stays where it always was, inside the migrator’s own dump-and-load path. And it does not get to reason its way around a gate.
Credentials stay out of the conversation too. The migrator’s read-only inspection calls run freely while anything that touches the target stops and asks.
Also in this Release
A few hardening items from the beta cycle that change advice given in the earlier posts:
- caching_sha2_password accounts now carry their passwords across. The earlier post described every SHA-based account landing on the temporary-password path with a credential rotation to follow. Where the target supports the plugin, the migrator now transports the hash intact, so those accounts log in after the move exactly as they did before.
- macOS is a supported control host. The migrator now runs from a Mac, not just a Linux migration host.
Get Started
- Download MariaDB Migrator from the Migration tools download page.
- Read the documentation.
- Read the AI Migration Tutorial
- Join MariaDB Slack for feedback and support
- Watch the webinar: AI-Assisted Migration From MySQL to MariaDB
Frequently Asked Questions
MySQL 5.7, 8.0, and 8.4.
MariaDB Community and Enterprise on-premises, and MariaDB Cloud. AWS RDS Sources and MariaDB Cloud have been validated as targets.
YES. The bash launcher and YAML configuration remain the primary interface, and everything the MCP path does is available directly from the command line. The assistant is an alternative front end, not a dependency.
Nothing. Both mariadb-migrator and mariadb-mtk are free to use and ship through standard MariaDB repositories.
Any client that speaks MCP and can reach the MariaDB MCP server. Our testing has focused on Claude.
It proposes; the tool decides. The migrator produces compatibility gates, preflight refusals, and the report itself. Anything that writes to a target requires your confirmation.
