Say the Name: MariaDB, MySQL, and the Ecosystem We Share
Names are important.
They help us identify people, projects, products, pets, database servers, and occasionally the correct bug tracker.
This may sound obvious, but the database world has spent more than fifteen years proving that it is not.
MySQL and MariaDB share a substantial amount of history, syntax, tooling, knowledge, applications, and community. They also have similar command names, compatible protocols, familiar configuration variables, and many users who simply say “MySQL” when they actually mean:
Some database server that speaks the MySQL protocol and probably has an executable named
mysqld.
And most of the time, everybody understands.
Until they don’t.
A MySQL Bug About MariaDB
Let’s take a recent example.
On July 24, 2026, a bug titled “Error build mariadb c connector 3.4.9 with openssl 3.5.7.9” was reported in the Oracle MySQL bug tracker.
The report contains a build failure from MariaDB Connector/C 3.4.9:
undefined reference to `EVP_PKEY_size'
The affected source path is also relatively explicit:
mariadb-connector-c-3.4.9-src/plugins/auth/caching_sha2_pw.c
And the suggested reproduction procedure starts by cloning what is supposed to be MariaDB Connector/C.
Yet the bug was submitted to: https://bugs.mysql.com
To be fair, the issue involves caching_sha2_password, which is historically associated with MySQL authentication. The MariaDB connector supports it because real-world software often needs to communicate with more than one server.
This is exactly what an ecosystem is supposed to enable.
But implementing compatibility with a MySQL authentication plugin does not magically make MariaDB Connector/C an Oracle MySQL product.
Otherwise, every application implementing the PostgreSQL wire protocol should be reported to PostgreSQL whenever it crashes (mmm, isn’t it the case also??… I should check the mailing list).
And every web browser problem should probably be filed against Tim Berners-Lee.
We Can Probably Fix MariaDB Faster Than MySQL Can
I would like to make a modest claim:
If you find a problem in MariaDB software, we can probably deal with it faster when you report it to MariaDB.
This is not because MariaDB developers have developed remote access to the Oracle MySQL bug tracker.
At least, not yet.
It is because the MariaDB developers maintaining MariaDB Connector/C work with the MariaDB project, its repositories, and its issue-tracking infrastructure.
The correct place to report a MariaDB issue is generally the MariaDB Jira: https://jira.mariadb.org
Reporting a MariaDB Connector/C bug to the MySQL bug tracker is a little like reporting a problem with your Audi to Volkswagen because both cars share some technology and history.
Volkswagen may understand the problem. They may even find it interesting.
But your chances of getting the correct engineering team involved improve significantly when you say the actual product name.
But Aren’t MariaDB and MySQL the Same Thing?
Yes… No…. This is where the fun begins.
MariaDB started as a fork of MySQL and deliberately retained a high degree of compatibility. Today, MariaDB is an independent database with its own trademark, governance, development teams, roadmap, features, repositories, release process, and bug tracker.
At the same time, MariaDB remains deeply connected to the wider MySQL technical ecosystem.
The two databases share:
- SQL syntax and behavior;
- client protocols;
- application connectors;
- administration concepts;
- configuration conventions;
- replication history;
- operational knowledge;
- and a community containing many of the same people.
As Kaj Arnö recently described it, MariaDB is simultaneously an independent database and part of the broader MySQL ecosystem. It shares MySQL’s roots and preserves compatibility for users, but it has its own future and technical direction.
In German, the answer might be Jein [1].
In database language, perhaps it is:
SELECT
mariadb_is_mysql_ecosystem_member = TRUE,
mariadb_is_oracle_mysql_product = FALSE;
Both rows can exist without violating a unique constraint.
The Trademark Problem
Part of the confusion comes from the word MySQL itself.
For many users, “MySQL” has become a generic technical category. They use it to describe the protocol, syntax, compatible connectors, administration skills, or the entire family of databases descended from the original MySQL codebase.
But MySQL is not a generic term legally.
MySQL is a registered Oracle trademark, and Oracle publishes specific conditions for using its names and logos.
MariaDB is also a trademark with its own usage guidelines.
This creates an interesting difference between how people speak and how products actually exist.
A user might say:
My application uses MySQL.
What they may technically mean is:
My application uses a connector implementing the MySQL client/server protocol and currently connects to MariaDB Server.
That second sentence is more accurate.
It is also less likely to fit on a conference badge.
So everyday language naturally simplifies things (A.N. I wish I could dig into this in the DB Engines poll).
The problem begins when the simplified name determines where documentation is searched, where compatibility assumptions are made, or where bugs are reported.
This question of identity and recognition is not new. In her article “I Am Not Building Cadillacs Anymore,” Anna Widenius uses the story of Henry Ford and Cadillac to describe a surprisingly similar branding problem: the origins may be shared, but the product being built today has another name.
As she puts it:
“We are not building Cadillacs anymore. We’re building MariaDB.”
The analogy fits rather well. MariaDB may come from the same engineering history as MySQL, but continuing to call everything “MySQL” gives recognition to the old name while making the current project, its contributors, and its innovations less visible.
And unlike my improvised Audi and Volkswagen comparison, this one has the advantage of being historically accurate.
Compatibility Does Not Mean Identity
MariaDB supporting MySQL behavior does not make MariaDB identical to MySQL.
Compatibility means that applications, tools, and people can move between the two systems with less friction.
That is a feature.
It does not mean the implementations are interchangeable in every detail.
MariaDB has functionality that does not exist in MySQL. MySQL has functionality that does not exist in MariaDB. Some similarly named features have different implementations. Authentication, JSON, GTIDs, replication, system variables, optimizer behavior, and metadata can differ substantially.
Even the things that look identical may have different code behind them.
This is why reporting precise information matters.
Instead of:
MySQL is broken.
Try:
MariaDB Connector/C 3.4.9 fails to link against this OpenSSL version on Debian Bookworm.
Now we know:
- which project is involved;
- which component is involved;
- which version is involved;
- which operating system is involved;
- and which team should examine it.
This is already a significant optimization.
No index was even required.
So, Is MariaDB Part of the MySQL Ecosystem?
I believe it is.
MariaDB users rely on decades of knowledge created by the MySQL community. Many applications support both databases. Many connectors can communicate with both. Conferences, user groups, books, blogs, and DBAs routinely discuss both.
My own career transition illustrates this rather well.
I spent years working in the MySQL community. I now work as a MariaDB Community Advocate. I did not wake up the following morning having forgotten SQL, InnoDB, replication, the binary log, or how to complain about badly chosen default values.
The skills transferred quite efficiently.
Possibly more efficiently than some database upgrades.
So yes, MariaDB belongs to the wider MySQL ecosystem in the technical, historical, and community sense.
But MariaDB is not Oracle MySQL.
The sea lion can swim with the dolphins without becoming a dolphin.
And when the sea lion has a problem, calling the dolphin support line may not be the fastest route to a solution.
Say the Name
The solution is not to build walls between the communities.
It is simply to be precise when precision matters.
You can talk about the MySQL ecosystem, you can discuss MySQL-compatible software, you can compare MySQL and MariaDB, you can reuse your MySQL knowledge with MariaDB, you can even use a MariaDB connector to connect to a MySQL server.
But when you report a bug, say the name of the product that produced it.
If the problem is in MySQL, report it to MySQL.
If the problem is in MariaDB, report it to MariaDB.
If the problem appears in both, congratulations: you may have discovered a genuine ecosystem feature.
In the specific case of MariaDB Connector/C, reporting the issue to MariaDB Jira gives the people maintaining that code a much better opportunity to reproduce, analyze, and fix it.
The MySQL bug tracker may be many things. But it is not currently a MariaDB Jira proxy.
At least, I could not find that feature in the documentation.