Any central service is going to be a point of failure. This isn't unique to RBMSes (the other classic SPOF is message buses).
The idea that RDBMSes are unsuitable for HA applications is ... well to be charitable, I'll call it "inaccurate".
Most of the techniques that are used for HA were first invented for conventional databases and/or their best friends, mainframes and midrange systems.
I agree however that it is a question of picking the right tool for the job.
I'm a data-safety bigot. I require a great deal of talking down from my tree. These days I can understand that, yes, OK, a consistent and durable model of Facebook comments probably isn't really that important.
But I will bet folding money that Facebook stores their financial data in a huge monolithic RDBMS datastore, like Amazon, Microsoft, Google and Apple do.
I agree with the historical point. But I think you miss mine: show me an open source RDBMS (I don't want to drop $annual_profit_margin on Oracle) with major-version upgrade capable HA while under load. My view: it doesn't exist. You could try to make it happen somehow, but it would be a huge project on its own.
On your somewhat loaded financial example, as someone who is designing some financial systems at the moment, I would instead argue that 'eventual consistency' is actually the de-facto model within the vast majority of business accounting, globally (credit card chargebacks, taxation systems, international (or domestic in the US) bank transfers, invoices/accounts receivable, etc.). Simultaneously truly real time and truly atomic requirements, particularly at scale, are rare.
Accountants invented the concept of a queue of transactions causing predictable updates. They also invented eventual consistency in the form of special and general ledgers.
However, ACID is four requirements and they're all still valuable and useful defaults. Atomicity comes from double-entry bookkeeping, consistency from the idea that data is meaningless without structure, isolation from the demands of consistency and durability because people get grumpy when you tell that that umpteen jillion dollars may ... or may not ... have been recorded.
Like I said, I'm a data-safety bigot. I greatly prefer to start with a safe default and then relax the guarantees. Retrofitting safety is harder, especially when you don't have a uniform statement of what your data is.
For something like a blog, an RDBMS is probably overkill. And MySQL got its start in life because it so thoroughly (silently) relaxed the standard guarantees that it was much faster than anything else.
> major-version upgrade capable HA while under load
The strategies are the same as for NoSQL.
Either you stop the world, or you run versions in parallel and drain traffic from the old versions.
I also find it slightly hilarious that just casually upgrading something without exercising great caution is seen as a good idea.
The idea that RDBMSes are unsuitable for HA applications is ... well to be charitable, I'll call it "inaccurate".
Most of the techniques that are used for HA were first invented for conventional databases and/or their best friends, mainframes and midrange systems.
I agree however that it is a question of picking the right tool for the job.
I'm a data-safety bigot. I require a great deal of talking down from my tree. These days I can understand that, yes, OK, a consistent and durable model of Facebook comments probably isn't really that important.
But I will bet folding money that Facebook stores their financial data in a huge monolithic RDBMS datastore, like Amazon, Microsoft, Google and Apple do.