3 ms·

Can you share your take on why MySQL and not Postgres?

erulabs 3y ago
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.
- brightball 3y ago
  > But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. Man...times have seriously changed if that's the case. Good for MySQL to improve enough to get that recommendation.
- raffraffraff 3y ago
  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.
lamroger 3y ago
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.

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.

brightball 3y ago
> But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. Man...times have seriously changed if that's the case. Good for MySQL to improve enough to get that recommendation.
raffraffraff 3y ago
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.

lamroger 3y ago

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.