Why SQL is beating NoSQL, and what this means for the future of data
This was a nice read for the history.  Honestly, being in a big legacy industry (Insurance), it&#x27;s as though NoSQL never happened.  We&#x27;re too big, at least my organization, to have made the wholesale change and we&#x27;ve been plugging along mostly in Teradata and DB2 for a long time.  Teradata in particular has performed well across a variety of use cases, its only large downside being the cost.<p>Anyhow, only point I&#x27;d add is that I&#x27;m not sure that SQL-like languages added on top of NoSQL solutions was really that bad of a thing.  It&#x27;s not as though there&#x27;s one flavor of SQL to rule them all on RDBMSs. I get that the bones are largely the same - SELECT, FROM, WHERE, most join types, aggregates, etc. But take a really common analytic use case - persisted transactional data.  Something like this -<p>SELECT
 A,
 B,
 C,
FROM SomeTbl
WHERE SomeDate BETWEEN SomeBegin AND SomeEnd
QUALIFY RANK() OVER (PARTITION BY A, B ORDER BY SomeOtherDate DESC) = 1<p>Pretty sure that SELECT, FROM, WHERE will work just about anywhere.  That QUALIFY clause is written for Teradata, and  once you get into the ordered analytic functions (as one example), you need to know the implementation relevant to the RDBMS you&#x27;re dealing with.  It&#x27;s not uncommon for a large enterprise to have MS SQL, DB2, Teradata, Oracle, etc. all under one roof.  As a data engineer, you still need to know the differences - first to get the data out, and then to optimize.<p>Dunno, I could be way off on this, but that&#x27;s been my experience at least.<p>I think the bigger issue is that you can use an RDBMS to do NoSQL-like things, such as key-value stores, with the flexibility to structure your data if you need that later.  So why not start with a relational database?