Things that are missing in most other proper databases, like transactional DDL. If you don't mind not having them, Mysql is fine. It's probably better than Postgres for mostly read databases, which is most uses. There was a time when Mysql was by far the most used but over the years it's growth has been fairly slow and Postgres has kept growing in use, mainly due to functionality and integrity.
People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources).
If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.
> People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares.
You seem to be under the impression that MySQL just "fails" on random read queries? That is nonsense.
In reality Facebook's db fleet is a massive sharded system, and sometimes shards are temporarily offline due to hardware failure on the shard's primary/writer node, but it's quite brief in the vast majority of cases. When you have such a massive number of servers, hardware failures happen many times a day.
Due to caching and other services it's also a multi-leveled data access stack, so a page load could fail due to some non-MySQL component having problems as well. Or a network issue, etc. It's not magically MySQL's fault every time something goes wrong at Facebook.
Meta uses MySQL for a variety of mission-critical use-cases, including financial ones. Every single committed MySQL write is replicated before success is returned to the calling code, nothing is lost or thrown away.
> Things that are missing in most other proper databases, like transactional DDL [...]
> some commercial thing like SQLServer or Oracle, where integritry is more highly important.
And yet Oracle DBMS does not have transactional DDL either, so why aren't you equally critical of it here?
Oracle can not group DDL changes in a transaction, but if an alter table results in an integrity violation the whole thing is rolled back, unlike mysql, that stops where the integrity violation occurs. Maybe Oracle is not as good as Postgres but it's workable. That's if you want to be shafted on licenses anyway.
That's simply not accurate! If an ALTER TABLE results in an integrity violation in MySQL, that ALTER TABLE is rolled back.
In modern MySQL, DDL is atomic and crash-safe on a per-statement basis. It's just not "transactional", in the sense that you can't combine multiple DDL statements (nor mix DDL and DML) into a single transaction.
Modern versions of MariaDB also have atomic DDL, although their underlying implementation is quite different.
And even in older versions of MySQL and MariaDB, an ALTER TABLE which causes an integrity violation was still rolled back. Think about it: the only possible non-instantaneous integrity violations are when adding a new unique key, new foreign key, or new check constraint. Check constraints didn't exist in old versions of MySQL or MariaDB, so that just leaves unique keys and foreign keys. And there's no notion of a "partially populated" index or a "half applied" foreign key constraint in MySQL, so your assertion of the ALTER just "stopping" mid-stream without rollback is just plain wrong.
People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources).
If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.