From my experience MariaDB is not necessarily better than MySQL. The 8.x line brought many interesting features. I dream on switch to Postgres, and try every year but for my use case MySQL is still superior (100Bi+ rows for large texts, and heavy modified - I´m also space constrained - So I need data compression and the VACUUM are not good.)
From my experience, mariadb is about the same as mysql... depending on the queries, it can either be fine, or slow as balls. I'm actually considering switching to pgsql to see if its any better. /shrug
The author is right that usage is dropping, but that really has no bearing on whether or not it is open source. Technologies get replaced all the time regardless of the license they use.
Author is also being careful with the DB-Engines screen shot, usage of MySQL may be dropping, but it's still number two (below Oracle, above MSSQL - which shows the same curve, above Postgres, far above MariaDB and SQLite) https://db-engines.com/en/ranking_trend
That site is not measuring usage. By usage SQLite would be way above all the others. There are more SQLite deployments in use than all the others combined.
I'm stuck on MySQL because converting to postgres is hard, the tool everyone recommends (pgloader) doesn't work with current MySQL (https://github.com/dimitri/pgloader/issues/782), anyone know another way?
How big of a DB are we talking about?
You might need to recreate the whole DB schema / structure manually from scratch in PostgreSQL and then dump the data and load it in PG via standard SQL file exports in the correct table order to avoid failures due to FK constraints.
This is a gross oversimplification but you get the gist
In fact I don't get the gist :) but thanks for your reply. All I know about databases is following instructions to set one up as part of a LAMP/FAMP installation.
Unless you use stored procedures in MySQL, recreating the tables and schemas in Postgres should be straightforward. Postgres now offers a 'MySQL Adapter', a.k.a. Foreign Data Wrapper (https://github.com/EnterpriseDB/mysql_fdw), that makes it straightforward to load data from MySQL into Postgres.
I know you mentioned that all you know about databases is following instructions, but maybe the folks at EDB or Percona can give you a hand.
Postgres will be around for a long time, and I think it's pretty obvious that MySQL won't.
It does work, I just used pgloader to migrate a 16 GB database from MySQL 8.4 to PostgreSQL 18 last week (around 700 tables). It's not big, but their problems seem to be with authentication, not database size or functionality.
Because it's a zero-maintenance solution that performs well out the box, has excellent analysis tools that are free, and works with no issues.
Postgres is work. Mysql is not. I say this having used mysql, postgres, oracle, sybase, mssql, ingres, rdb, dbase, and other random data stores in production.
Obviously lots and lots of companies. Do you think a mature company just migrates to a different database unless it is absolutely necessary? That's a multi year project. I'm at a smaller company (around a 100 devs) and we have easily a dozen different production instances, some small and some larger with many replicas, etc.
New projects get MySQL too because we know it and it works.
> Do you think a mature company just migrates to a different database
You are right if you look at the current state of how MariaDB and MySQL diverged. But if you migrated right at the time of the split or close to, they were not different in a meaningful way.
> unless it is absolutely necessary
Staying free of Oracle is often deemed absolutely necessary.
MySQL performs well at large scale, and has a very cool and weird storage engine option called MyRocks, that slows read performance but allows demented write rates and compression.
I would argue that the reason to stop using it is that is a pretty bad piece of software to begin with, not because it's not "true open source" but hey, whatever floats your boat, right?
I'm not going to stop using it because it's not "true open source." I'm going to stop using it because there's better databases out there.
From my experience MariaDB is not necessarily better than MySQL. The 8.x line brought many interesting features. I dream on switch to Postgres, and try every year but for my use case MySQL is still superior (100Bi+ rows for large texts, and heavy modified - I´m also space constrained - So I need data compression and the VACUUM are not good.)
The percona distribution is very good!
The storage engine is one of postgres's weakest points. I hope OrioleDB will eventually give us a more robust and easier to use replacement.
Is there anything in 8.0.x/8.4.x line that isn't present in MariaDb latest?
From my experience, mariadb is about the same as mysql... depending on the queries, it can either be fine, or slow as balls. I'm actually considering switching to pgsql to see if its any better. /shrug
If space constrained and wanting compression, why not do that at the filesystem or block layer if it's not supported in the app?
The author is right that usage is dropping, but that really has no bearing on whether or not it is open source. Technologies get replaced all the time regardless of the license they use.
Author is also being careful with the DB-Engines screen shot, usage of MySQL may be dropping, but it's still number two (below Oracle, above MSSQL - which shows the same curve, above Postgres, far above MariaDB and SQLite) https://db-engines.com/en/ranking_trend
The rankings methodology looks like it will favour MySQL.
https://db-engines.com/en/ranking_definition
Lots of historical mentions. Even the MariaDB website mentions it. Lots of people say "MySQL" generically to include its forks.
You can see that in this comment thread too. People assuming MariaDB=MySQL (not according to op, arguable)
That site is not measuring usage. By usage SQLite would be way above all the others. There are more SQLite deployments in use than all the others combined.
I'm stuck on MySQL because converting to postgres is hard, the tool everyone recommends (pgloader) doesn't work with current MySQL (https://github.com/dimitri/pgloader/issues/782), anyone know another way?
How big of a DB are we talking about? You might need to recreate the whole DB schema / structure manually from scratch in PostgreSQL and then dump the data and load it in PG via standard SQL file exports in the correct table order to avoid failures due to FK constraints. This is a gross oversimplification but you get the gist
In fact I don't get the gist :) but thanks for your reply. All I know about databases is following instructions to set one up as part of a LAMP/FAMP installation.
Unless you use stored procedures in MySQL, recreating the tables and schemas in Postgres should be straightforward. Postgres now offers a 'MySQL Adapter', a.k.a. Foreign Data Wrapper (https://github.com/EnterpriseDB/mysql_fdw), that makes it straightforward to load data from MySQL into Postgres.
I know you mentioned that all you know about databases is following instructions, but maybe the folks at EDB or Percona can give you a hand.
Postgres will be around for a long time, and I think it's pretty obvious that MySQL won't.
I'll read up on that, thanks!
Prepare to be replaced by ai
haha. I have lots of other valuable skills. There's more to programming & IT than just db administration you know.
What happens if there are cycles of FK constraints between rows?
It does work, I just used pgloader to migrate a 16 GB database from MySQL 8.4 to PostgreSQL 18 last week (around 700 tables). It's not big, but their problems seem to be with authentication, not database size or functionality.
Have you tried it doing it yourself?
I have tried. It fails in authentication like that ticket describes, so I seem to be stuck on square one.
Why would anyone use MySQL over Postgres in 2026?
Because it's a zero-maintenance solution that performs well out the box, has excellent analysis tools that are free, and works with no issues.
Postgres is work. Mysql is not. I say this having used mysql, postgres, oracle, sybase, mssql, ingres, rdb, dbase, and other random data stores in production.
Because they started with MySQL and it can be difficult to switch.
Happily using MariaDB (as packaged with Debian) in production here...
Oracle's icy touch. It was foretold. :D
One does not need to stop because "its not open source", one needs to switch because its no longer actively being developed.
I used MariaDB in Azure, but got notified it was retired. Anyway, migrated to sqlite.
my client insists on mysql to stay compatible with amazon RDS
Who's still using MySQL on the back end? Most Linux distributions come with MariaDB. Is it Windows servers?
I'm pretty sure Facebook is still running it. They've done a migration to 8.0 a couple of years after it came out (it was a massive release).
https://engineering.fb.com/2021/07/22/core-infra/mysql
Obviously lots and lots of companies. Do you think a mature company just migrates to a different database unless it is absolutely necessary? That's a multi year project. I'm at a smaller company (around a 100 devs) and we have easily a dozen different production instances, some small and some larger with many replicas, etc.
New projects get MySQL too because we know it and it works.
> Do you think a mature company just migrates to a different database
You are right if you look at the current state of how MariaDB and MySQL diverged. But if you migrated right at the time of the split or close to, they were not different in a meaningful way.
> unless it is absolutely necessary
Staying free of Oracle is often deemed absolutely necessary.
MySQL performs well at large scale, and has a very cool and weird storage engine option called MyRocks, that slows read performance but allows demented write rates and compression.
But yes, it is very bad.
I would argue that the reason to stop using it is that is a pretty bad piece of software to begin with, not because it's not "true open source" but hey, whatever floats your boat, right?
[dead]