MySQL vs MariaDB schema differences catch a lot of teams off guard, because the two databases share so much surface area — the same wire protocol, most of the same SQL syntax, even the same mysql client — that it's tempting to treat a MariaDB target as "basically MySQL." At the schema level, though, they have quietly diverged in ways that will break a naive migration or a copy-pasted DDL script. Here's what actually differs, and why it matters when you're comparing or porting schemas between the two.
JSON is not the same type in both
MySQL added a native binary JSON column type in 5.7, with its own storage format and validation built into the server. MariaDB never adopted that type. Instead, JSON in MariaDB is a plain alias for LONGTEXT, with a CHECK constraint quietly attached to validate that the stored text is well-formed JSON. Functionally the two look similar for basic reads and writes, but they are not the same column under the hood: a MariaDB "JSON" column is a text column with a constraint, while a MySQL one is a distinct binary type with its own indexing and function behavior. A schema-diff tool that only compares type names as strings will call these a match when they aren't.
Sequences exist on one side, not the other
MariaDB 10.3 introduced a real CREATE SEQUENCE object — a standalone counter you can reference from multiple tables, reset, or query directly. MySQL has no equivalent; it still relies entirely on per-table AUTO_INCREMENT columns. If a MariaDB schema uses a sequence to generate keys across several tables, there's no direct MySQL construct to migrate it to — you have to redesign around AUTO_INCREMENT or an application-side generator, not just translate syntax. This is one of the sharper edges between the two dialects, similar in spirit to how sequences, identity columns, and auto-increment differ across the wider database landscape.
Generated columns: close, but not identical
Both databases support GENERATED ALWAYS AS (expression) columns with VIRTUAL or STORED modifiers, and the basic syntax lines up. MariaDB adds PERSISTENT as an accepted synonym for STORED, which MySQL doesn't recognize — a script written against one dialect's documentation can fail on the other over a single keyword. Function support inside the generated expression also drifts release to release, so an expression that's valid on MariaDB 10.x may not parse the same way on a given MySQL version, and vice versa.
CHECK constraints weren't always enforced the same way
MySQL accepted CHECK constraint syntax for years without enforcing it — the parser allowed it, the server silently ignored it, all the way up to 8.0.15. Enforcement only arrived in 8.0.16. MariaDB started enforcing CHECK constraints earlier, from 10.2.1. That gap means a MySQL schema exported from an older instance can carry CHECK clauses that were never actually protecting the data, and moving that same DDL onto MariaDB (or a newer MySQL) can suddenly start rejecting rows that had been silently invalid all along. Worth checking alongside other collation and charset pitfalls before you run a cross-dialect migration.
Why "just point it at MariaDB" undersells the risk
None of these differences show up as a connection error — MariaDB happily accepts the MySQL wire protocol and most MySQL DDL, so a migration can appear to succeed and only fail (or silently misbehave) later, when a JSON validation rule doesn't fire the way it used to, or a sequence-based ID generator has nowhere to go. The safest approach is to treat MySQL and MariaDB as related but distinct dialects and diff schemas between them explicitly, object by object, rather than assuming DDL is portable because the client tools are.
Comparing MySQL and MariaDB schemas directly
FoxSchema treats MySQL and MariaDB as separate dialects rather than aliases of each other, so a schema comparison between them surfaces type and constraint differences instead of masking them. You can point it at a MySQL source and a MariaDB target (or the reverse), review exactly what changed, and generate migration SQL written in the target dialect's own syntax. Read more in the docs, or self-host it and run a comparison against your own databases.
