I was at GitHub in 2017 when that GitLab outage happened. We had 60 million users running on vanilla MySQL no Vitess at that point. We had 10 million users literally running on 3 MySQL servers. Don't pretend that even now Postgres can do that.
If you knew enough to switch to innodb and "mysql_real_utf8_string" or whatever it was, you had a quite performant and stable system.
People that directly experienced this very thing will probably chime in to give examples (etc). :)
A 'true' DBMS will provide some guarantees and rather fail a transaction than do a 'best endeavours' job with it.
It's not an exaggeration to say that trying to keep mysql from corrupting your data feels like a full-time job. Mysql in many ways, especially as used by massive social media companies early on was closer to a SQLish DSL for a non-transactional kv store than a "real" ACID database.
That's why "but it can do 70k rps" is just noise to someone. I don't care how fast it can lose my data.
I'm all for people needing to read the docs but man a database burns trust pretty fast when it's so easy to have it pretend to support transactions or pretend to support utf8.
The gap has for sure closed in many areas but I still feel safer with Postgres today because there's been little reason for me to try MySQL again.
Good luck with that.
Meanwhile MySQL's default settings have included strict sql_mode (giving a hard error on data type mismatches, overflows, etc) for eight years.
These have been available as non-default options for 20+ years, and larger MySQL users have long enabled them before they were defaults.
Yes, the defaults certainly should have changed earlier, especially re: strict sql_mode, I won't dispute that. However on the default storage engine side, the historical reasoning makes perfect sense: InnoDB and MySQL were owned by different companies. Oracle purchased the makers of InnoDB in 2005 and didn't purchase Sun (incl MySQL) until 2010. Once both products were owned by Oracle, they made InnoDB the default storage engine in the next major MySQL release that same year.
In any case, your claims of "decades of misleading marketing" about transactions is completely fictional. This simply did not happen for "decades" and has not been a discussion point of any sort for a very, very long time. Serious MySQL shops were never using MyISAM at scale in the first place.
That's a completely nonsensical reply to the contents of my comment. I'm not the same person you were originally responding to up-thread.
I took time out of my Sunday to write a fact-based rebuttal to your false claims in this thread. The dates in my comment are all verifiable on Wikipedia, among other places. And yet your response is childish repetition, followed by a citationless comment claiming that my own comment was misinformation.
Since you're a Golang enthusiast (as am I), perhaps I can reframe this in a more relatable way. Imagine that it's the year 2035, and there's an HN thread about Golang. Some Go-hater chimes in that no one should ever trust Go because of decades of misleading marketing ("no one needs generics!"), GOPATH being stupid, and lack of a module dependency system. What would your response to this be in 2035, knowing full well that these issues were far in the past and that the claim of "decades" is at best an extreme exaggeration?
That's the kind of bullshit I'm meaning. I have no energy left to deal with trolls, and that means you.
A decade is 10 years. Plural decades means 20 or more years.
You claimed MySQL made decades of misleading marketing about transactions. That would mean they were making such statements in 2015 or later.
That is verifiably factually incorrect, considering that InnoDB (a fully ACID-compliant storage engine) was made the default storage engine in 2010, and prominent MySQL users had already switched to InnoDB en masse from 2005 to 2008, some even earlier. The previous storage engine (MyISAM) was garbage that wasn't even crash-safe, so at scale its deficiency was plainly obvious.
I am not posting "bullshit" or "trolling". Your statement was incorrect and this is simple date math.
However, you can absolutely run that many users on a Postgres cluster of that size today on modern hardware. Connections are absolutely a sore point and probably my number one pain point as a Postgres admin day to day. Pg bouncer is incredibly easy to run though. You rarely actually need 70,000 connections most will be idle most of the time anyway it’s not like MySQL can actually serve 70,000 queries on 70,000 connections simultaneously. But it certainly makes administration and the programming model more difficult.
Large MySQL users are generally not turning off acid guarantees. That is nonsense. What settings are you even specifically referring to with this?
On the durability side, large MySQL shops only mess with innodb_flush_log_at_trx_commit if there's a safe distributed durability mechanism in use (e.g. synchronous or semi-synchronous replication). Or perhaps if the data is ephemeral/recomputable, but that's a similar use-case to running Postgres on a ramdisk.
On the isolation side, MySQL supports READ UNCOMMITTED (unlike Postgres) but it is very rarely used. Only useful for some specific situations. fwiw MS SQL Server supports it too, it's not a MySQL specific thing.
Also note that folks aren’t running giant vanilla MySQL clusters. They’re running it through vitess or home grown tools with similar functionality.
Finally MySQL gets performance in these large setups by turning off features like foreign keys, acid guarantees etc. it’s awesome and powerful that you can do this in MySQL but it’s not apples to apples here. MySQL has also improved a lot on these dimensions in the last few years.
The other reality here is that on nvme hardware with a few tb of ram you can get away with a basic reader writer replica setup for a long time.