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.

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.

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.

Maybe you should link up with the JSONiq team and establish a new standard to compete with SQL.

That said, ArangeDB is cool - keep up the good work!

Does anyone know why they chose to make AQL diverge from SQL so much?

As far as I can tell from a cursory glance, FOR -> SELECT, IN -> FROM, FILTER -> WHERE, SORT -> ORDER BY.

Is there a reason the authors didn't use the more familiar SQL keywords?

> Because it's a graph database so it doesn't really fit naturally with SQL.

Interesting, but lacking in details. The trivial examples I see in posts like this always seem to map perfectly to SQL.

I agree, we should show more examples.

AQL was indeed inspired by XQuery. We made some user acceptant tests at the very start and used a version which was using keywords from SQL and a more descriptive approach with keywords from programming languages. At least our test users were mostly confused by a similar SQL-syntax but slightly different SQL sematic.

We talked to the JSONiq guys. They had a look as XQuery and AQL and made a similar decision.

https://www.arangodb.com/key-features#aql does a relatively good job explaining it. The examples are all fairly simple, in a real world app you have much more complicated queries and it's here where arango really shines imho. With SQL it's very easy to write inefficient queries by accident, whereas AQL is a lot more explicit.

Looks like a FLWOR statement in XQuery.