When MariaDB was first announced in 2009 by Michael “Monty” Widenius, it was positioned as a “fork of MySQL”. I think that was a Bad Idea™. Okay, maybe it wasn’t a bad idea as such. After all, MariaDB indeed is a fork of MySQL. But what is a fork in the software sense, and how is this reflected in MariaDB? A fork is a software project that takes the source code of another project and continues development independently from the original. Forks often start by maintaining compatibility with their parent project, but they can evolve to become detached with their own features, architecture, bug tracker, mailing list, development philosophy, and community. This is the case of MariaDB, with the addition that it continues to be highly compatible with old MySQL versions and with its current ecosystem at large.

Before we dig into it, let me clarify that I like MySQL. It was the very first database that I installed during my university time, and I have used it in hobby as well as production projects for a long time. So, why did I affirm that positioning MariaDB as a fork of MySQL was a bad idea? In short, because MariaDB doesn’t depend on MySQL. The idea of defining MariaDB merely as a fork of MySQL leads to misconceptions around its future. Take as an example this old comment on Hacker News which refers to the phrase “RIP Open Source MySQL”:

“Forgive my ignorance, but doesn’t this harm MySQL forks as well? Since the test cases are unavailable from now on, say for example they wanted to reimplement a certain feature, isn’t it much harder for them to validate that their implementation works correctly?”

I sympathize with the author of this comment. We were unintentionally misled by the “fork of MySQL” slogan. I encounter this kind of lack of clarity more often than I would like. But the reality is that the development of MariaDB has been independent for many years already. MariaDB developers don’t wait for MySQL to implement features, test cases, fix bugs, or innovate. They write their own tests, create their own features, and solve problems in their own way. When Oracle changes something in MySQL or restricts access to a component, that has no meaningful impact on MariaDB’s roadmap because the projects have diverged so significantly that they’re essentially different database systems that happen to share some common ancestry, be highly compatible (you can use MySQL connectors and tools with MariaDB), and are named after Monty’s children.

So, how come projects like Ubuntu “depend” on upstream projects (e.g. Debian) and others like MariaDB don’t? In his paper Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!, David A. Wheeler (Director of Open Source Supply Chain Security at the Linux Foundation), identifies four potential outcomes for software fork attempts:

1. The death of the fork: The most common outcome, since keeping a software project alive requires considerable effort.
2. A re-merging of the fork with the original: Both software projects rejoin each other.
3. The death of the original: Users and developers move to the new younger project.
4. Successful branching: Both find success with different developers and end users.

For years, the MySQL-MariaDB situation was clearly a successful branching where both projects found new homes. One in Oracle, the other in the new MariaDB Foundation / MariaDB plc duo. Contrary to what many would have thought, Oracle invested in MySQL and continued its development in the open despite having its own close-source relational database. For a period of time, MariaDB kept merging MySQL code commit by commit. However, this changed in 2014 when Oracle stopped publishing MySQL’s source code on Launchpad. Even though MariaDB still merges changes from InnoDB, this marked a clear point of divergence in codebases.

Recent (and not so recent) findings and events show that Oracle has slowed down at least on the innovation front and at worst on the maintenance side. In his article Stop using MySQL in 2026, it is not true open source, Otto Kekäläinen (former Software Development Manager at AWS), shows that “the number of git commits on github.com/mysql/mysql-server has been significantly declining in 2025.” He also highlights the steep decrease in MySQL’s popularity according to DB-Engines, as well as the reported “degraded performance with newer MySQL versions.” Are we witnessing a “death of the original” here? I don’t know.

In light of all this, many developers are starting to evaluate migration strategies to other relational databases with MariaDB and TiDB being two of the most attractive options. According to Otto Kekäläinen, “TiDB only really shines with larger distributed setups, so for the vast majority of regular small and mid-scale applications currently using MySQL, the most practical solution is probably to just switch to MariaDB.” How about the elephant in the room, you might ask? PostgreSQL is a database with tons of forks and third-party extensions that you can download which makes it popular not only due to its features but the sheer number of companies marketing their PostgreSQL flavor online. For applications currently using MySQL, migrating to PostgreSQL requires a lot of work including SQL code and connector migrations. Two tasks that can be close to zero-effort with MariaDB. Check for example this crazy live broadcast where Cantamen (Germany’s leading car-sharing service provider) migrates from MySQL to MariaDB with the help of Monty himself.

Let’s get back to my highly opinionated introductory statement… MariaDB is a—now we have learned—detached fork of MySQL, and, to be fair, it has also been positioned as a “MySQL replacement” which is something very accurate to state. I’m glad to see the “replacement” slogan more and more often as opposed to the “fork” one. I personally suggested to Kaj Arnö (Executive Chairman at the MariaDB Foundation) going with something even stronger like “MariaDB fixes MySQL”. That’s a bit too strong, perhaps. I’m glad they softened it to “MariaDB is the Future of MySQL”.

Enjoyed this post? I can help your team implement similar solutions—contact me to learn more.