Yes! It was an era when people knew what they were talking about or had the good sense to keep their mouths shut.
"not all SQLs are the same" SQL is an international standard. The core of most commercial relational database management systems (RDBMS) is the same and follows this standard. What you're describing are the custom features that each vendor, e.g. Microsoft, IBM, Oracle, etc, has added over the years. Calling these features SQL is simply wrong and misleading. They're not part of the SQL standard and ergo are not SQL.
"It's all relational databases? Always has been." Nope. You're completely ignoring (or unaware of, except that you mention them, while minimizing their importance, a little further down) the absolutely staggering amount of database processing in banking, insurance, government, etc that continues to take place on mainframes and minis.
"For many of them [small applications], an RDBMS is a massive overkill to begin with." Why? Completely unsupported opinion.
"Only the popularity of relational databases has led developers to pick them." Wrong again. Competent, knowledgeable developers pick RDBMSs to capture and persist highly normalized entity data BECAUSE THEY ARE THE RIGHT TOOLS FOR THAT JOB. Today, NoSQL databases are being selected only because they're popular, shiny, and new with no thought whatsoever about the tasks they're going to have to complete or the capabilities those tasks will require.
"mostly because there are really few learning resources out there that teach you how to build relational databases properly" Completely disagree. There are now more resources than ever before, and they're much less expensive and much quicker and easier to access. Learning how to do something properly is hard, and people are lazy. That's why object relational mappers (ORMs) exist -- so that developers don't have to learn SQL. But some things are abstract and conceptually difficult. That doesn't mean that we shouldn't learn them.
Learning how to do something properly isn't what universities are for anyway. Universities aren't trade schools.
"A relational database and the principles of designing these push you towards centralization of your data inside that database." Not if you use them correctly. A screwdriver is going to "push you" to the emergency room if you try to use it as a can opener.
"the relational database that we’ve used for so many years turned out to not scale so well" Oh, Rick Houlihan of MongoDB says that his competition doesn't scale. Where's my shocked face? Amazon Web Services (AWS) Relational Database Service (RDS) and Aurora (as well as my own 30-year career) beg to differ. Also, I continue to hear that relational databases don't scale well, but there's never any evidence presented to support this claim. It just seems to be something that people who don't actually know what they're talking about like to say to each other.
"ACID compliance is totally irrelevant for the use case of an Internet search engine. No one in his right mind would use an RDBMS for a large scale Internet search engine or a social media site." True. And conversely, no one in his/her right mind would use a NoSQL database to capture and persist highly normalized entity data.
Your "Relational Database Systems Are Becoming A Problem" premise is beginning to wobble. The issue isn't with RDBMSs; it's correctly understanding the task at hand and selecting the proper tool. RDBMSs are optimized for highly efficient, transactional data capture (data IN). Data warehouses and NoSQL databases are optimized for reporting and analyzing (data OUT) and for persisting semi-structured and unstructured data.
And it's not just ACID compliance. By their very nature relational databases have things like ... well, relations built in using mechanisms like foreign keys, which automatically enforce vitally important things like relational integrity, i.e. they won't allow you to orphan related records. In your "perfect", "utopian" world of NoSQL, the team has to write, test, and maintain that logic themselves. Yippy!
"The approach of using purpose built data management only works if you strictly adhere to microservice architectures and don’t build “micro serviced monoliths” in which you have micro services all working on a single centralized data management system like a relational database. It’s a common occurence to find micro service architectures paired with monolithic databases which completely render the micro service approach useless." Uhhhh, what? I'm a fairly smart guy. I've read this three times now, and it's still just gibberish. What is it that you feel you've stated or proven here?
"The first choice for data storage of applications should be basic key value stores like Apache Cassandra, AWS DynamoDB, Google Cloud Spanner or Azure Cosmos DB." Absolutely incorrect.
The first choice for data storage of applications should be ... to correctly identify and understand the type(s) of data that the application will capture, process, and provide and to select the appropriate tool for each.
I'm going to break off here because you now begin to dismantle your own fatally flawed "Relational Database Systems Are Becoming A Problem" thesis and instead begin to make my "choose the right tool for the job" point.
So to sum up, relational databases are not, have never been, and are not becoming a problem. People choosing the wrong tool(s) for the job, often based on poor advice (ahem) are and will always be the problem. Don't blame the tools.
