Migrate MySQL to MariaDB

Certified — live-tested path

Migrating from MySQL (the world's most deployed open-source relational database) to MariaDB (the community-driven MySQL fork) means every table, column type, key, index and row has to survive two engines' different opinions about data. 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.

Start MySQL → MariaDB Migration

Free tier · no credit card

MySQL vs MariaDB

MySQL

the world's most deployed open-source relational database.

MariaDB

the community-driven MySQL fork.

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.

MySQL to MariaDB data type mapping

Pulled directly from DBShifts's own conversion rules — not a general reference table, this is what actually runs.

MySQL	MariaDB	Note
INT	int
BIGINT	bigint
SMALLINT	smallint
TINYINT(1)	tinyint(1)	MySQL and MariaDB store booleans here. Plain TINYINT is numeric — the width is the only thing distinguishing them.
DECIMAL(10,2)	decimal(10,2)
FLOAT	float	Binary floating point, same rounding caveat as DOUBLE.
DOUBLE	double	Binary floating point. Money stored in a DOUBLE will round; use DECIMAL end to end.
VARCHAR(255)	varchar(255)
TEXT	text
LONGTEXT	longtext
CHAR(10)	char(10)
DATE	date
DATETIME	datetime
TIMESTAMP	timestamp	Timezone behaviour differs per engine — a naive target shifts the instant rather than failing.
TIME	time	MySQL TIME is a duration spanning -838:59:59 to 838:59:59, not a clock time. Targets with a 24-hour TIME cannot hold the full range.
YEAR	year	MySQL-only type. Widened on every other engine.
BLOB	blob
JSON	json	JSON is stored and indexed very differently per engine; queries against it will need rewriting.
ENUM('a','b')	enum('a','b')	Value list is kept as a CHECK constraint where the target supports one.
SET('a','b')	set('a','b')	No equivalent outside MySQL and MariaDB. The value list is preserved but the constraint is not.

Example: MySQL to MariaDB schema conversion

MySQL

CREATE TABLE orders (
  id            INT AUTO_INCREMENT PRIMARY KEY,
  customer_id   INT NOT NULL,
  status        ENUM('new','paid','shipped') NOT NULL DEFAULT 'new',
  total         DECIMAL(10,2) NOT NULL,
  is_gift       TINYINT(1) NOT NULL DEFAULT 0,
  notes         TEXT,
  metadata      JSON,
  placed_at     DATETIME NOT NULL
);

MariaDB

CREATE TABLE IF NOT EXISTS `orders` (
    `id` int NOT NULL,
    `customer_id` int NOT NULL,
    `status` enum('a','b'),
    `total` decimal(10,2) NOT NULL,
    `is_gift` tinyint(1),
    `notes` text,
    `metadata` json,
    `placed_at` datetime NOT NULL,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

MySQL → MariaDB 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.
Literal 'NULL' defaults reported by MariaDB's information schema are cleaned instead of becoming DEFAULT 'NULL' strings.
AUTO_INCREMENT reseed after bulk load, same as MySQL.

Frequently asked questions

Is MySQL to MariaDB migration production-ready in DBShifts?

Yes — MySQL to MariaDB is a certified pair. It passed DBShifts's live certification suite (schema conversion, data transfer, row counts, type-aware checksums over an edge-case fixture) and is battle-tested in production use.

How does DBShifts verify the MySQL to MariaDB 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 MariaDB 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 MariaDB 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 MariaDB?

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 MariaDB?

Type-system mismatches that fail silently rather than loudly — MySQL's edge-case types (5 engine-specific rules apply) converting into MariaDB's nearest equivalent. DBShifts's deterministic mapping records every downgrade in the fidelity report, so a value that clips, rounds, or widens is visible before cutover, not after.

Which MySQL data types change when moving to MariaDB?

9 of the mapped types convert to something that cannot represent exactly the same range or constraint. The clearest cases are TINYINT(1) to tinyint(1), FLOAT to float, DOUBLE to double. The full table above lists every mapping the converter performs, and analysis flags each one on your actual schema before any data moves.

Go deeper

How We Live-Certified All 49 Migration Paths

The certification harness behind this page's claims.

Why Row Counts Aren't Enough

How type-aware checksum validation works.

Related migration paths

MySQLMySQL MySQLPostgreSQL MySQLSQL Server MySQLOracle MySQLSQLite MySQLMongoDB

Ready to move MySQL to MariaDB?

Set up in under two minutes. Validation and rollback included.

Start Free Migration