What actually breaks when you import a MySQL dump into MariaDB

Short version: a mysqldump file from MySQL 8 restores into a current MariaDB with far fewer edits than most advice online assumes, because MariaDB 11.4.5 started aliasing MySQL's utf8mb4_0900_* collations onto its own. What still breaks is a short list: DEFINER clauses on views, triggers and routines; users and grants that were never in the file to begin with; utf8mb3 columns that import cleanly and cost you four-byte characters later; and two mysqldump flags that most people only find out about by reading an error.

This is the companion to the walkthrough in moving a MySQL database off cPanel shared hosting. That post is the procedure. This one is the error reference, and it applies to any MySQL source: a shared host, a droplet you are decommissioning, RDS, PlanetScale, a laptop.

The collation error, and why you probably will not hit it

The single most repeated piece of MySQL-to-MariaDB advice is that your dump will die on this:

ERROR 1273 (HY000) at line 24: Unknown collation: 'utf8mb4_0900_ai_ci'

MySQL 8 made utf8mb4_0900_ai_ci the default collation, MariaDB implemented Unicode 14 collations under a uca1400 name instead, and for several years the two did not know about each other. Every dump from a default MySQL 8 install carries the collation name in each CREATE TABLE, so the restore stopped at the first table.

That was fixed. MDEV-35256 aliases MySQL's language-neutral 0900 collations onto the MariaDB 1400 equivalents, closed as fixed with a stated fix version of 11.4.5 (checked 2026-08-26). MariaDB's own collation reference now lists utf8mb4_0900_ai_ci with the description "Alias for utf8mb4_uca1400_nopad_ai_ci".

So the error is a version question, not a compatibility question. On 11.4.5 or newer, the dump restores. On an older series it fails exactly as advertised, and 10.11 is the LTS most people still land on when they pick "the stable one" from a version dropdown. On Layerbase the default for a new MariaDB database is 11.8, and 10.11 is still offered, so this is a real choice you make at create time rather than something the platform decides for you.

If you are stuck on an older server and cannot move, the fix is a search and replace over the dump before you load it:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' dump.sql

That is a sort-order change, not a rename. utf8mb4_general_ci orders differently from a UCA 14 collation, which matters if you rely on ORDER BY for anything a human reads. Prefer the newer server.

DEFINER: error 1227

This one has not gone anywhere:

ERROR 1227 (42000) at line 812: Access denied; you need (at least one of) the SUPER privilege(s) for this operation

MySQL's server error reference gives 1227 as ER_SPECIFIC_ACCESS_DENIED_ERROR, SQLSTATE 42000, message "Access denied; you need (at least one of) the %s privilege(s) for this operation" (checked 2026-08-26). In a restore it almost always means one thing: your dump contains an object stamped with the account that created it on the old server.

/*!50017 DEFINER=`olduser`@`localhost` */

mysqldump writes that stamp onto views, triggers, stored procedures, functions and events. Creating an object owned by an account that is not you needs elevated privilege, and on any managed database you are not the superuser. On a shared host the definer is usually something like cpaneluser_wp@localhost, an account that does not exist anywhere else in the world.

Strip it on the way in:

sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' dump.sql > dump-clean.sql

The objects then get created owned by whoever runs the restore, which is what you wanted. There is no --skip-definer on mysqldump to save you the step; the option existed on mysqlpump, which Oracle deprecated. Check what is actually affected before you assume it is nothing:

SELECT TABLE_SCHEMA, TABLE_NAME, DEFINER FROM information_schema.VIEWS
WHERE TABLE_SCHEMA = 'yourdb';

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA = 'yourdb';

SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA = 'yourdb';

Empty results on all three and you can skip the sed entirely. Most small application databases come back empty, which is why plenty of people move without ever meeting error 1227.

While you are here: --triggers is on by default, and stored routines and events are not. If the three queries above return rows, your dump command needs --routines --events or those objects silently do not travel. That failure has no error message at all, which makes it worse than 1227.

Users and grants were never in the file

A database dump contains schemas and data. It does not contain accounts. MySQL's documentation is direct about this: mysqldump does not export user accounts or grants, because those live in the mysql system schema, which you dump separately and should not restore onto a different server.

On shared hosting this bites harder than it sounds, because cPanel-style panels create a user per application with a prefixed name, and applications hold that name in config files. After the move you get one account from the managed provider with a generated password. Anything in your codebase that references the old username changes.

Take an inventory before you tear the old server down:

SELECT user, host FROM mysql.user;
SHOW GRANTS FOR 'olduser'@'localhost';

You are reading it to find out what your application actually needed, not to replay it. A managed database hands you a single account with rights over your own schema, so the interesting question is whether anything was relying on a second account with narrower rights, and almost nothing is.

utf8mb3 imports fine, which is the problem

Nothing errors here. That is what makes it worth a section.

Databases created on MySQL 5.x default to the character set the server was configured with, and on a lot of older shared hosting that is utf8, which is not what it sounds like. MySQL's manual is unambiguous: utf8mb3 is deprecated, "remains supported for the lifetimes of the MySQL 8.0.x and MySQL 8.4.x LTS release series", and the guidance is that "all new applications should use utf8mb4" (checked 2026-08-26 from the utf8mb3 reference page).

utf8mb3 stores at most three bytes per character, which covers the Basic Multilingual Plane and excludes emoji, many CJK extension characters, and a pile of symbols people paste into text fields. A table declared utf8 on the old host arrives on the new one still declared utf8mb3, still working, still unable to store a rocket emoji. You find out when a user submits one and the write fails or the string truncates at the emoji.

Find out where you stand before the move, not after:

SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'yourdb' AND CHARACTER_SET_NAME IS NOT NULL
  AND CHARACTER_SET_NAME <> 'utf8mb4';

The conversion is per table:

ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4;

Do it on the new server, after the restore, one table at a time, with a backup you can go back to. Converting rewrites the table and widens every character column's storage, which is a real consideration on any index built over a long VARCHAR: a 255-character column goes from 765 bytes of index key to 1020. On modern InnoDB row formats there is room for that. On an ancient one there is not, and the ALTER tells you so rather than corrupting anything.

If the old database is genuinely ASCII-only, converting still costs you nothing and closes the question permanently.

The two flags you learn about from an error

Both of these fire on the dump side, before you have gone anywhere, and both are confusing because the error names something you never asked for.

mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, ...)':
Unknown table 'COLUMN_STATISTICS' in information_schema (1109)

MySQL 8's mysqldump asks the server for column histogram statistics by default. Servers that do not have that table, which includes MariaDB and MySQL 5.7, answer with 1109. It is not a corruption signal and it does not mean your data is unreadable. Add --column-statistics=0 and it goes away.

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s)
for this operation' when trying to dump tablespaces

This is error 1227 again, wearing a different hat. mysqldump asks the server about tablespaces, that question needs the PROCESS privilege, and a shared-hosting account does not have it. --no-tablespaces suppresses the CREATE TABLESPACE and CREATE LOGFILE GROUP statements you were never going to use.

Put together, the dump command that survives contact with a restricted source account looks like this:

mysqldump \
  --single-transaction \
  --no-tablespaces \
  --column-statistics=0 \
  --routines --events \
  --default-character-set=utf8mb4 \
  -h HOST -u USER -p DBNAME > dump.sql

--single-transaction is the one worth understanding rather than copying. It takes a consistent snapshot without locking, which works because InnoDB is transactional. It does nothing for MyISAM tables, which a fifteen-year-old shared-hosting database often still has. Check first:

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'yourdb' AND ENGINE <> 'InnoDB';

Rows in that result mean your snapshot is not consistent for those tables and you should stop writes during the dump, or convert them to InnoDB first and then dump.

Checking the restore actually landed

Row counts are the check people run and the weakest one, because a truncated dump that stopped at table 40 of 60 gives you perfect row counts for the first 39.

SELECT COUNT(*) FROM information_schema.TABLES  WHERE TABLE_SCHEMA = 'yourdb';
SELECT COUNT(*) FROM information_schema.VIEWS   WHERE TABLE_SCHEMA = 'yourdb';
SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'yourdb';
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'yourdb';

Run those four on both sides and compare the numbers. Views and routines are where a DEFINER failure or a missing --routines shows up, and neither of them affects a single row count.

Then take the largest three tables and compare COUNT(*) and MAX(id), and run SHOW CREATE TABLE on both servers for one table with an interesting schema. Character set and collation are printed there, so it doubles as your utf8mb3 check.

Two related posts worth reading if this kind of thing keeps you up: what a SQLite import can silently get wrong is the same class of problem in a different engine, and database dump determinism covers why two dumps of identical data do not always match byte for byte.

FAQ

Can MariaDB read a MySQL 8 dump?

Yes, on a current version. MariaDB 11.4.5 added aliases for MySQL's utf8mb4_0900_* collations, which removes the failure that older guides describe. What still needs handling is DEFINER clauses on views, triggers and routines, plus the fact that users and grants are not in the dump at all.

What does "Unknown collation: 'utf8mb4_0900_ai_ci'" mean?

Your target server predates the MySQL collation aliases. It is MySQL error 1273, and it means the CREATE TABLE named a collation the server does not know. Restore into MariaDB 11.4.5 or newer, or search and replace the collation name in the dump and accept a different sort order.

How do I fix "Access denied; you need the SUPER privilege" on import?

Strip the DEFINER= clauses from the dump. Your file contains views, triggers or routines stamped with an account from the old server, and creating an object owned by another account is a privileged operation you do not have on a managed database. The sed line in the DEFINER section above is the usual fix, and the three information_schema queries next to it tell you whether you need it at all.

Do my MySQL drivers work against MariaDB?

Yes. MariaDB speaks the MySQL wire protocol, so mysql2, Prisma, Drizzle, PDO, and the mysql and mariadb command line clients all connect without a code change. Where the two engines genuinely diverge is features, not connectivity, and MySQL vs MariaDB walks through the differences that matter.

Will my emoji survive the move?

Only if the columns holding them are already utf8mb4. A column declared utf8 on an older MySQL is utf8mb3, holds three bytes per character, and cannot store emoji at all. It restores without complaint into MariaDB and stays broken. Query information_schema.COLUMNS for anything that is not utf8mb4 and convert those tables after the restore.

Should I import into MySQL or MariaDB?

If you have no reason to prefer one, MariaDB, because your dump restores unchanged either way and MariaDB is the one on our free tier. MySQL starts on the Solo plan at $5/mo. If you use MySQL-specific features like multi-valued JSON indexes, stay on MySQL.

Where to put it

Create the target first, then dump, so you are not sitting on a file with nowhere to go. A MariaDB database on the Free plan costs $0 with no card, covers 2 databases and 5 GB of storage, and takes a mysql client restore like any other server. If the database is going to serve a live site, the Solo plan at $5/mo is the one to be on, because it includes an always-on allocation you can pin the database to so it never sleeps.

If the source is still reachable over the network, you can skip the dump file entirely: paste a mysql:// connection string into the import wizard at cloud.layerbase.com/create, pick MariaDB as the target, and we run the dump and load once against a source we never write to.