The mathematical theory that SQL builds on is very solid, and being a mathematical construct I'd argue makes it an "ideal interface" as it captures almost all u

The mathematical theory that SQL builds on is very solid, and being a mathematical construct I'd argue makes it an "ideal interface" as it captures almost all useful data-table operations in a consistent and concrete logical framework. SQL as a language? Meh. Powerful but often clunky and many of the most powerful constructs are implementation specific (support CTE's vary a lot). It always strikes me that almost every project seems to ditch direct SQL coding for ORM's. The best code interface to SQL I've found is Elixir's Ecto project, which turns functional constructs into appropriate SQL statements. Otherwise both Postgres and MySQL use proprietary binary wire formats. New DB's like cockroachdb choose an existing binary protocol, or use ODBC. Not really sql interfaces, as in the textual ansi standard. Still it seems like an industry standard around something like RethinkDB's query AST supporting generalized set of tuple-calculus or relational algebra operations and extra features could provide a much better and consistent code-to-DB interface. Then whether it's a key-value store supporting only a few operations or a full "SQL" interface, it could possibly enable much more innovation and even cooperation. For example, a relational-algebra functional DSL or sql-text interface could be used on the same data store. The one major missing feature in this scheme would be transactions, though it's almost certain the mathematics for describing transactions on datasets has been hashed out many times.