While everything, including the Wikipedia definition of SQL defines it as tied to relational databases, one of our industry's biggest flaws is not realizing tha

While everything, including the Wikipedia definition of SQL defines it as tied to relational databases, one of our industry's biggest flaws is not realizing that the basic concept of a Structured Query Language is that it can handle nearly all types of structures, including non-relational ones. Take a look at the most recent versions of the SQL standard, say SQL:2016, and you see it handles document type data (JSON) pretty well too. The syntax isn't what we're used to, but it works pretty well. I know that SQL can do more when you separate its conceptual foundation from relational databases. It's an expression language, an interface language to structured data. I used to work on a platform that could translate SQL into NoSQL databases and SQL databases alike, it involves translating the expression into something that fits the native data model. For something similar look at Apache Drill, Dremio, Hive or PrestoDb and how they hide different types of databases behind interfaces that make them compatible with SQL. I can admit, shoehorning SQL as it is onto a non-relational source (ex. Graph databases or search) isn't totally clean. But I believe it can evolve further as a standard to address that. It requires more work in middleware to interface between SQL expressions and heterogeneous technology. And getting creative with the language constructs themselves. The power of data projection, data shaping and filtering alone, not to mention aggregation, etc. is undeniable in my opinion. Disclaimer: I used to work for a company that built data federation software which supported SQL in front of heterogeneous sources. So what I am saying I know to be factual in most cases (although difficult!).