MySQL users usually switch for a different licence home, deeper SQL features, an embedded engine, distributed scale or fast analytics. Drop-in forks suit teams who want compatibility with what they already run, object-relational servers suit complex data work, embedded engines suit apps with no server, and distributed or analytical databases suit scale and reporting. Otherwise, staying on MySQL is fine.
Most people who type this search are reacting to one bad week: a slow report, a licence worry, a host that's changing its offer. That's a fine reason to look around, but a poor reason to pick. So start with the job, then the database.
Name the problem before you name a database
Write one sentence that finishes "we need to move because..." and be honest about it. It nearly always lands on one of five things, and each one points to a different kind of engine.
- Who owns it worries you. You want the same behaviour under a different steward or a licence promise you trust. That's a fork or a compatible build.
- Your SQL has outgrown it. Nested queries, richer data types and heavy joins are where an object-relational server earns its keep.
- You don't want a server at all. A desktop app, a mobile app or a small internal tool that one process writes to is happier with an engine that lives inside the program.
- One machine has run out of room. Only here does spreading the database across several servers make sense.
- Reports are slowing the site down. That's an analytics job, and it usually wants a second engine rather than a replacement.
If you wrote two of these, pick the one that's costing you money or sleep today. Solving the wrong one gives you a migration and the same problem.
Four decisions that shrink the shortlist
Compatible or rewrite. A fork promises your existing queries, users and tools keep working. Anything else means checking every query, and anything built for a different job means rewriting some of them. Count the hours honestly before you fall for a feature list.
Your server or someone else's. Running it yourself gives you control and puts backups, upgrades and 3am failures on your team. A managed database from your cloud provider takes those away and limits you to the engines and versions they offer. Check that list first, because it may decide for you.
One machine or many. A distributed database survives a lost server and grows by adding machines, but you pay in moving parts, network latency between nodes and a steeper learning curve. A single well-sized server with a replica handles far more traffic than most sites will ever see.
Transactions or analysis. Everyday app work is lots of small reads and writes. Analytical engines are built to scan millions of rows for a handful of columns. Ask one to do the other's job and both look slow.
If you're torn between the two most common moves, read MariaDB vs MySQL and MySQL vs PostgreSQL before you commit to either.
Eight databases people move to
MariaDB
The fork started by MySQL's original developers, aimed at teams who want an enhanced drop-in replacement and a firm open-source promise.
Percona Server for MySQL
A compatible build from a specialist MySQL firm, for production sites that want MySQL's behaviour, on open-source software, without retraining anyone.
PostgreSQL
An object-relational, open-source server that extends SQL, the usual destination when queries and data models have grown beyond what MySQL handles comfortably.
SQLite
A serverless, zero-configuration engine that runs inside your app, with public-domain code: ideal for desktop software, mobile apps and small single-writer tools.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
CockroachDB
Cockroach Labs' distributed cloud database, worth a look when a single server can't keep up and you want SQL spread across machines.
TiDB
An open-source distributed SQL database pitched at transactional and AI applications, for workloads that have outgrown one box.
ClickHouse
A real-time analytical database that usually sits beside your main one, taking on dashboards and reports over very large tables.
DuckDB
A small analytical engine you can run almost anywhere, handy for crunching exports on a laptop with a query language modelled on PostgreSQL.
A one-hour test on your own data
Feature pages tell you what a database can do. An hour with your own schema tells you what it will do for you. You'll need a copy of your database, Docker or a spare machine, and your slow query log if you have it switched on.
- Export the schema only with
mysqldump --no-dataand load it into the candidate. Every error at this step is a migration task you'd have hit later. Write each one down. - Pull your ten slowest queries from the slow query log, or ask your developer for the ten pages that feel sluggish, and the queries behind them.
- Load a masked sample of real data. Made-up rows hide the odd dates, empty strings and character sets that break migrations.
- Run each query in both databases and compare the row counts and a handful of actual rows. Different results are worse than slow results.
- List every tool that connects: your CMS, backup scripts, the admin panel, monitoring, any plugin with its own driver. Tick each one off against the candidate's documentation.
- Stop the candidate in the middle of a write and restart it. Watch what your application does when it comes back.
At the end of the hour you'll have a list of breakages and a feel for speed on your own workload. If the list is short, plan a fuller trial. If it's long, you've just saved yourself a month.
What has shifted in the category
The clearest shift is in how databases describe themselves: at least one of the distributed options on this list now names AI applications next to transactional ones. That's a label, not a reason to move. If an AI feature is on your roadmap, add one query that does the AI-shaped job to your one-hour test and judge it on your data, the same as everything else.
Mistakes that turn a move into a mess
- Moving to a distributed database "for the future" when one server is barely breaking a sweat. You inherit the complexity years before you need the scale.
- Replacing the main database to fix slow reports, when adding an analytical engine beside it would have left the site untouched.
- Trusting the word "compatible" without running your own queries. Close isn't identical, and the gaps hide in edge-case functions and default settings.
- Forgetting the hosting control panel, which may only offer one engine and quietly rules out the rest.
- Switching off the old database too soon. Keep it ready for rollback until the new one has come through a busy week.
Where the money goes
No vendor publishes a typical cost for moving off MySQL, and I'd be wary of anyone who quotes one before seeing your schema. What you can do is know where the bill comes from. The servers or managed instances are charged by size, storage and sometimes data transferred. Paid support or an enterprise edition is optional, and priced on request or by usage. The biggest line for most teams is people: hours spent testing, rewriting queries and watching the switch. Your one-hour test is the best estimate you'll get, because every breakage on that list is a task someone has to be paid to fix.
Where I'd point you
Match the pain you wrote down at the start to the move:
- Uneasy about who's behind it: a fork or compatible build. It's the shortest move, and you can test it in an afternoon.
- Fighting the SQL: an object-relational server. The rewrite is real, and it pays back every week after.
- App on one device: skip the server and embed the engine.
- Slow reports: keep MySQL and add an analytical engine beside it.
- One large server truly full: only now take on a distributed database.
None of the five? Then the answer at the top of this page stands, and the time you'd have spent migrating is better spent tuning what you have.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
