MariaDB doesn't have a commitment to binary compatibility with MySQL, though. For a time it was marketed as a drop-in replacement, but that has been increasingly untrue for over a decade now.

Aha, I didn't know that. Looks like the marketing worked too well on me! In any case, the lie of drop-in compatibility at least I think led some people to look for alternatives that wouldn't be hampered by Oracle-era MySQL.

I didn't either until it bit me in the ass a few months back - often it's shitty proprietary software being only compatible with "genuine" (oracle) MySQL.

To be fair to vendors, it's increasingly difficult to maintain compatibility with both! Here's my very long rundown of the differences in tables/DDL alone: https://www.skeema.io/blog/2023/05/10/mysql-vs-mariadb-schem...

...and that doesn't even account for differences in global variables/configuration, SQL syntax, functions, replication, etc.

This is very informative, thank you.

This is the most direct explanation. The blog post avoids talking about this at all, but I'm guessing that's to keep the post informative and not let it degrade into a database flame war.

As a MySQL DBA for the past 20 years it was practically the only choice until Oracle bought Sun, then it was instantly radioactive. A shame because the fears people had were unfounded and some of the best development work has been done since then.

Postgres already had cachet before Oracle bought MySql, but it was seen more as a small scale oracle replacement for people who were serious about data integrity or for lower volume OLTP work in the web sphere. The MySql acquisition coincided with performance gains by Postgres that made it more applicable to web scale OLTP workloads, and JSONB support was really the nail in the coffin.

This is exactly when I tried pgsql for the first time and never looked back.