For me it's mostly about known-knowns. I've been responsible for pretty large/company-critical MySQL clusters and have managed to sleep soundly at night. I tend to be the "database guy" at every startup, and those startups tended to use MySQL.
I have to say, I do love PostGIS. But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. I can and have debugged MySQL replication on zero hours of sleep. It's entirely possible Postgres 16 is the better choice for new projects today, but I haven't had the time to try it out in production yet.
It amazes me how much better MySQL has been in this regard for at least a decade, and it's also amazing that it's still not that well-known today. Back in 2015 I worked at a fast-growing unicorn that had badly implemented basically everything because they started with a tiny ops team of grads and developers. Very little was being monitored, there were only a handful of metrics being graphed (mostly network stuff in Cacti). Our DB issues were all caused by stupid stuff :
* undetected hard disk in array fails
* battery in array controller fails
* disk fills up
* dubious backups, with no point-in-time recovery
* extremely poorly written SQL queries
* poory configured MySQL (in oh-so-many ways)
The top three (at least) would lastly cause replication lag, which would eventually trigger an alert. ... And yet we never lost a cluster. (And we far a lot of them!)
My team sweated blood improving processes and tooling, and then I spent a 6 month stint on database clusters (switching to GTID based replication and rewriting the ops config code so that they were all consistently configured and monitored).
Occasionally we'd get a new senior hire insist that PostgreSQL was a necessity, so we'd stand back and let them produce a proof of concept that stood up to the types of failures our MySQL clusters dealt with regularly, without waking oncall up at night. And it was always a bit of a joke by comparison.
I haven't worked in big tech but I imagine their tooling is really good for this particular stack. Internal expertise too for running into big scale edge cases.
erulabs|2 years ago
I have to say, I do love PostGIS. But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. I can and have debugged MySQL replication on zero hours of sleep. It's entirely possible Postgres 16 is the better choice for new projects today, but I haven't had the time to try it out in production yet.
brightball|2 years ago
Man...times have seriously changed if that's the case. Good for MySQL to improve enough to get that recommendation.
raffraffraff|2 years ago
* undetected hard disk in array fails
* battery in array controller fails
* disk fills up
* dubious backups, with no point-in-time recovery
* extremely poorly written SQL queries
* poory configured MySQL (in oh-so-many ways)
The top three (at least) would lastly cause replication lag, which would eventually trigger an alert. ... And yet we never lost a cluster. (And we far a lot of them!)
My team sweated blood improving processes and tooling, and then I spent a 6 month stint on database clusters (switching to GTID based replication and rewriting the ops config code so that they were all consistently configured and monitored).
Occasionally we'd get a new senior hire insist that PostgreSQL was a necessity, so we'd stand back and let them produce a proof of concept that stood up to the types of failures our MySQL clusters dealt with regularly, without waking oncall up at night. And it was always a bit of a joke by comparison.
lamroger|2 years ago