Did you document your research in any more detail (specific examples, attempts to map SQL to other data models), which lead to AQL? Would be interested in comparing notes, as I have done research in mapping at least document/directed graph and key value pairs into "table" like structures, and it is quite doable (and there are some products which already do it). With features from SQL99 and above, we even have industry standard representations of array data types as well, for example.<p>The reason I ask is, I love the idea of ArangoDB's multiple models approach. Also, I followed JSONiq and 28.io earlier and felt similarly about their FLWOR based query language. I do understand and respect the power of such an approach when it comes to other data structures.<p>That said, I have some first-hand experience with a fairly reasonably sized user base, and while they have some difficulty understanding SQL, I don't see them understanding AQL more than SQL, and it seems like most attempts to replace SQL have somewhat harder road. Also, unfortunately, most tools (BI tools, data mining tools) do not support alternatives to SQL (yet), making something like Arango somewhat more limited to the technical set who understand and can exploit the syntax. Depending on your goals, it can unnaturally limit the reach to your user base.<p>Maybe you should link up with the JSONiq team and establish a new standard to compete with SQL.<p>That said, ArangeDB is cool - keep up the good work!
Does anyone know why they chose to make AQL diverge from SQL so much?<p>As far as I can tell from a cursory glance, FOR -> SELECT, IN -> FROM, FILTER -> WHERE, SORT -> ORDER BY.<p>Is there a reason the authors didn't use the more familiar SQL keywords?