SQL’s sequel: SQL

SQL’s been around for a long time. It’s old school. Behemoth’s like IBM, Oracle, and Microsoft are deeply committed to RDMS systems that are essentially defined by a standard, well-accepted language for access. SQL emerged in the 70s, became ANSI and ISO standards in the 80s, with SQL systems forming the backbone of Internet servers since the dawn of the Network Age.

Then along comes NoSQL … first it was “No SQL” with Carlo Strozzi’s Unix-like interface to an RDMS in the late 90s to a slew of key/value databases in the previous decade with entrants like CouchDB and MongoDB. And Column databases like HBase and Cassandra. And Graph databases like Neo4j.

But now it seems NoSQL may also mean something else. “Not YET SQL.” One of the giants in the RDMS world, Michael Stonebraker, certainly seems to think so. So, it would seem, does Teradata

presto -- one SQL to rule them all

presto — one SQL to rule them all

.

With Teredata’s recent embrace of presto it’s clear that SQL as a conceptual interface and standard language for a litany of storage choices makes good sense for a number of reasons. This is not to say that SQL will be the only choice for data access — not by a long shot. But it does mean that in case there was any doubt, SQL as a data access language and relational calculus paradigm is here to stay regardless of the structure of the underlying databases.

Want to join a hive query with some my mysql records? No problem. Cassandra with Postgres? You bet. Some JMX mixed in for good measure? No problem. It’s only a matter of simply-configured connectors to turn presto into a single point of query.

The industry has been looking for SQL’s sequel since I can remember. And now it’s here. It’s SQL. Big Data requires it, and competitive pressures demand it. Even while bringing a much-needed layer of clarity to a gnarly Big Data problem, presto helps makes SQL cool again.