Like many conferences, KubeCon 2018 had a variety of distributed database vendors. But what is unusual this year is that every single one of them InfoQ talked to emphasized their support for SQL.

CouchBase offers N1QL (pronounced "nickel"). This is an extension to ANSI SQL with support for JSON constructs. It offers JDBC and ODBC drivers in addition to custom clients for specific platforms.

YugaByte describes itself as a "Transactional NoSQL" database that offers "Planet Scale SQL". It uses the PostgreSQL wire format along with its propriety SQL extension, YSQL. This means you can leverage existing PostgresSQL drivers in your language of choice. According to the company,

As firm believers in open source and open APIs, building a proprietary SQL API was not even an option for us. However, which existing SQL flavor to build compatibility with became a non-trivial question given the abundance of SQL flavors in the market. In the end, we selected PostgreSQL as our SQL of choice. We were truly impressed by the openness, maturity and feature completeness of PostgreSQL. These attributes have created a highly passionate and thriving community of users. Industry analysts are also observing these same trends that have led to a big resurgence of PostgreSQL especially over the last 5 years. Matt Asay's recent post "Why Oracle's missteps have led to PostgreSQL's ‘moment' in the database market" analyzes the trends in a fair amount of detail.

CockroachDB was the third vendor interviewed for this article. They implemented both the PostgreSQL wire format and SQL dialect. They choose the PostgreSQL wire format not only because it is open sourced with a compatible license, but also because it was very well documented. In order to ensure as much compatibility as possible, they even used a PostgreSQL's syntax parser, with extensions where necessary.

MongoDB renewed their SQL offering with a new ODBC driver. This if a commercial extension meant to allow the use of "MongoDB as a data source for Tableau, Excel, MicroStrategy, Microsoft Power BI, [and] Qlik".

The Need for SQL

Several factors are driving the adoption of SQL in modern distributed databases. For some it is simply a way to make adoption easier. If a company can lift their existing relational database into a cloud database with little or no change to the code, it becomes much easier to get the project green-lighted.

Business Intelligence tools are another driving factor. While there are differences between SQL dialects to consider, it is still much easier to build a BI tools that supports multiple databases when all of those database use SQL instead of completely proprietary query languages. As mentioned above, MongoDB explicitly stated their SQL implementation was designed to support BI tools.

Though not widely discussed, there is also the issue of training. Both developers and non-technical staff are often trained in standard SQL. Many colleges offer this as an elective or extension class. This makes it a better alternative to having staff learn a unique query language for each database in a large enterprise system.

ANSI SQL and JSON

Though not well supported by database vendors, ANSI SQL does actually define what JSON operations should look like in the SQL 2016 standard. In a report last year, Markus Winand outlined support for JSON by the major relational database vendors in an article titled What's New in SQL:2016.

A glaring omission in the 2016 standard is lack of a partial update. Markus writes,

The SQL standard does not provide functions to update parts of JSON documents (like json_set in MySQL, PostgreSQL, and SQLite or json_modify in SQL Server).

This will have to be addressed in a future version in order to allow interoperability between the various distributed, JSON-based database vendors.