Not sure how you manage to miss the point of the article. I'll break it down for you:
* A lot of traditional sql solutions have scaling issues.
* A lot of nosql solutions for these issues have become popular in recent years. Their main use case is web scale (simplification)
* A ton of actual use cases fall between those two chairs i.e they would have scaling issues with traditional sql systems but don't really have billions of transactions to process.
The article presents some valid real world approaches for this third case, some of it might be case dependant but overall pretty good advice.
they would have scaling issues with traditional sql systems but don't really have billions of transactions to process.
If you have scaling issues with traditional SQL systems, the first thing you should do is understand your problem, not cargo-cult to a different paradigm.
More specifically:
* You do not get to complain about SQL transaction speed if you use denormalized tables.
* You do not get to complain about SQL transaction speed if your primary keys are varchar(50).
* You do not get to complain about SQL transaction speed if you store all non-identifying data in a single json blob.
* A lot of traditional sql solutions have scaling issues.
* A lot of nosql solutions for these issues have become popular in recent years. Their main use case is web scale (simplification)
* A ton of actual use cases fall between those two chairs i.e they would have scaling issues with traditional sql systems but don't really have billions of transactions to process.
The article presents some valid real world approaches for this third case, some of it might be case dependant but overall pretty good advice.