It's amazing how when you use recent technology that has been designed and engineered from the ground up for the demands of modern web apps, you can devote a lot of other resources to the actual product and usability.
"Why would you give these up for scalability problems you won't have, with 99.999999% probability?"
I'm not saying people shouldn't use RDBMS', but there are many reasons for using something else:
- The new databases/stores have different features and use cases. Many include features RDBMS' do not have.
- Having to use table/column's for everything can be quite unnatural and tiresome.
- RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds.
- At least for me, using & learning something new is a big motivation booster :)
Use whatever is right for the job. But one should at least have a general knowledge of whats out there: features, pros & cons etc..
"The new databases/stores have different features and use cases. Many include features RDBMS' do not have."
True. My view is that the tradeoff comes out overwhelmingly on the RDBMS side most of the time.
"Having to use table/column's for everything can be quite unnatural and tiresome."
Unnatural in the sense that it is different from the first language you learn, yes. What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation.
"RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds."
I really think you need to learn something about RDBMS fundamentals. Set theory certainly "holds" to this day, and is certainly not legacy. The relational model is clumsy for some kinds of data ( (e.g. time series), but saying that the foundation is obsolete is just objectively false.
"At least for me, using & learning something new is a big motivation booster"
No argument there. But now take the next step and do an objective comparison between old and new. I have no problem with NoSQL systems. I even built one. But for nearly all applications, when you account for a wide set of requirements, (not just what is needed to get the MVP up and running), I think an RDBMS is the right tool.
"What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation"
Again, that depends on what you are doing. Converting back and forth between rows/tables and, say, data stored in hashes, is tiresome. It's also unnatural when the data doesn't "fit" in the relational model. Of course it works, but writing all this banal sql is not fun.
"I really think you need to learn something about RDBMS fundamentals...."
Right.. I was talking about the software. Maybe "models" is the wrong word.
"But now take the next step and do an objective comparison between old and new"
The funny thing is hierarchical databases were all the rage in the 1960s (IBM's IMS for example) and the world moved on to the RDBMS.
I chuckle to myself when kids who wouldn't know a "legacy" app if it jumped up and bit them on the nose, go through the same thought process over and over again.
b) that said recent technology also only fits a niche for modern web apps?
I think you view on what constitutes modern web apps or software in general is biased in favor of some examples who benefit by using mongo/couch/redis whatever. (And are very vocal about it)
[EDIT: spelling, and to add that I have tremendous joy in playing with couch, redis, node lately. But at the same time I try to stay critical: what are the real trade offs when I employ these tools?]
Hmm, let's see. What does a "modern web app" do? Well there is a screen with fields for users to enter something, and there is another screen where things that (other) users have previously entered formatted nicely for display. Behind the scenes, this data is exchanged between machines that do some other processing on it.
