Yes, AQL was inspired by XQuery. I think SQL is really good for querying relational databases. Actually we started with implementing something like SQL's SELE

Yes, AQL was inspired by XQuery. I think SQL is really good for querying relational databases. Actually we started with implementing something like SQL's SELECT clause in the very beginning of ArangoDB. The rationale was: "why invent another language? SQL is everyhwere, so let's use it!". We very soon found that SQL is not a good fit for working with semi-structured data. There is no definite schema for a collection in ArangoDB, so it is unknown which attributes (think: columns) a document (think: row) will have. Thus using standard SQL would have introduced a lot of potential ambiguities. Example: SELECT a, b, c FROM c1 INNER JOIN c2 ON (c1.x = c2.y) When inspecting the above query initially, the database has no idea if attribute "a" will come from c1 or c2. Each document in both collections can have an attribute "a", "b", "c" or none at all. So a query like the above could throw an ambiguity error at runtime only, and not at query compile time. Fully qualifying attributes with "table" names would have worked (e.g. "SELECT c1.a"), but would be a deviation from standard SQL, which doesn't require that. And then people would have asked "they claim to support SQL. But why doesn't my SQL statement work in ArangoDB?". Probably a lot of confusion. Apart from that, it is common to have multi-valued attributes in document databases (and thus in ArangoDB). Think of an attribute which itself is a list. SQL really is not designed for this. Putting a horizontal lists into a single attribute/column is an anti-pattern in the relational world. Instead, you would normalize most data into separate n:m mapping tables etc., and join them later. No need to do this with a document database: horizontal lists are supported, and there is less NEED for normalization. It is up to you how to model the data. With all that in mind, we very soon switched to a language we thought would better fit a non-relational database such as ArangoDB. We intentionally decided against using SQL keywords, to avoid confusion. I hope the decision for starting AQL now is little more comprehensible.