In some of these cases MySQL is not being used as an RDBMS.
And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database.
Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y").
I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL?
Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.
It does invalidate claims that using product X is going to inevitably cause you huge problems once you "grow enough". I've seen a lot of places grow a lot while using MySQL, and the problems aren't really that different or more serious than in places using Postgres or Oracle.
In fact, I know enough places moving from Postgres to MySQL due to growing pains.
Right, but we're not talking here about scale. We're talking about ... trustworthiness, I suppose. Dependability.
What this article demonstrated is that MySQL will often give a false sense of security. That's not what you want from a system ostensibly meant to provide a number of important technical guarantees.
Multi-master is the one tickbox feature where MySQL is still clearly in front. Once the PostgreSQL team finish going about inbuilt multi-master in their usual meticulous, stepwise fashion (my WAG is that it'll land by 9.6), there really won't be any good technical reasons left to use MySQL.
But I didn't mean "grow" in exclusively performance meaning. I meant the whole package (as with growth the requirements for reliability also ultimately show up, at least in some parts of the business). Even my current job that involves a lot of MySQL has important chunks of Must Never Go Away Or Else data, with a lot of complex insert/update action going on them, and somehow it's working fairly well for us.
One of the persistent themes of the linked piece is that MySQL simply conceals many kinds of fault. "Somehow it's working fairly well for us" may be right. Or it might not. Either way, MySQL isn't going to warn you.
With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data.
It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.
Defaults count. Elsewhere I've said that I prefer to start with rigid guarantees and relax them. Default policy matters because in practice:
* The documentation isn't read.
* Even when it's read, the documentation may be incomplete.
* When it's read and complete, the crucial segment may be skimmed.
* When the documentation is complete and the crucial segment was read, it may have been misunderstood because of unclear writing.
* When the documentation is complete and the crucial segment was clearly written and read, it may be forgotten later on.
Then a new DBA or programmer arrives, and the whole thing starts all over again.
Safety mechanisms that require active effort above the baseline configuration do not work very well. Saying "there is a great mechanism" does not describe the actual properties of the actual system. The default policy is the policy that counts, because a single omission will reintroduce it.
Windows XP, buffer overflows, botched system deployments and so on all have a common property: they require positive effort by humans in order to rise above their baseline safety/security/reliability profile. There is no failsafe -- they only work by constant vigilance.
And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database.
Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y").
I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL?
Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.