SQL doesn't fit every use case. Ansi-SQL being the standard, has been extended on by most vendors. I too often get frustrated by the idea of learning some new q

SQL doesn't fit every use case. Ansi-SQL being the standard, has been extended on by most vendors. I too often get frustrated by the idea of learning some new query dialect, but context matters. In the case where a vendor creates something that looks like SQL, it's frustrating if the basics that I expect from ANSI-SQL aren't there. This especially if my data is stored relationally. If the database/store doesn't behave or store data relationally, SQL often doesn't work well. At least you need some mechanism which the vendor might not want. I can't expect to use SQL for a graph database. It also might not work so well for a KV store that doesn't have relations/joins. MongoDB's query language is actually good. I know they support SQL on the enterprise product, but it feels like a compromise. I suppose the rant has some merit, but I'm trying to say that SQL can't solve everything. An interesting project is Apache Calcite, which gives a single SQL query model to various data stores. Perhaps one could write a plugin if they really want to use done random database that doesn't use SQL.