Unfortunately, because of the article's brevity, I find the article attempts to (but ultimately fails to) emphasize the details/reasons behind a key point enoug

Unfortunately, because of the article's brevity, I find the article attempts to (but ultimately fails to) emphasize the details/reasons behind a key point enough. It might be this article was written for a more general audience. The key point I'm referring to is that many of the developments of modern databases are really expansions on ideas that were invented back in the 1960's but have been re-invented in the distributed world, to handle higher data volumes and advances in hardware/software capabilities. For example, the article overlooks (and most seem to overlook) a critical technology known as multivalue databases, which are mid-1960's technology, predate relational systems, and share a lot in common with more recent NoSQL systems in terms of the persistence paradigms. The main difference is that multivalue databases were centralized systems and not distributed - but data volumes were a lot smaller back then compared to the volumes we have now. I bet most would be surprised to know that Pick/D3, a legacy multivalue database, was an integrated operating system, database and programming language, and that it contained a "SQL" like query language (without joins, aggregates, etc. - very simplistic) as well as attempts at natural language query-like utilities. Pick/D3, in particular, lost out to the relational players in the 70s and beyond for a multitude of reasons. That said, it and technology like it (MUMPs, for example) are still alive and running systems today. Intersystems Cache, for example had interesting concepts that mixed object-relational mappings and SQL queries on top of a system that started as something resembling a persistent multi-dimensional array, MUMPs. In the context of the history that I understand, everything is an evolution in thinking for data storage, data volumes, persistence, networking, data access techniques, etc. NoSQL, for instance, is a terrible misnomer - for many such systems suffered in adoption because of a lack of a good general purpose query language (although many now provide their own forms of query languages to make working with data they store easier). That said, having a structure which is non-relational in form has never meant you could not use SQL with it - just that some of the relational constructs do not fit as easily into those realms. We need not look further than Hadoop to understand how relational paradigms can be extended to any form of data/system with the right combination of technology components (think Hive, Spark, etc. etc). We are in a world now where we have a multitude of data engine paradigms, where no one model truly and completely dominates the other - they are complementary and each have strengths and weaknesses. And we continue to get closer and closer to combinations of techniques that allow for general purpose, distributed by default, data systems/processing/storage.