I don't understand under what specific use case ArangoDB works best; the comparisons section lists Cassandra and Neo4j, and my understanding was Cassandra was for something like chat apps and Neo4j was for something like GIS analytics. Enlighten me?
Also, how convertible is a proprietary query language like AQL/CQL to SQL? Is it fully declarative, and version completely independently of the database core?
AQL is versioned along with the database core, as sometimes features are added to AQL which the database core must also support and vice versa. However, during further development of AQL and the database core, one of the major goals is to keep it always downwards-compatible, meaning that existing AQL queries are expected to work and behave identically in newer versions of the database (but ideally run faster or are better optimized there).
We were absolute idiots, but I still think a data warehouse should be idiot-proof, which is why I like SQL.
I read through the documentation for ArangoDB and I would be concerned about the lack of native strict type definitions and referencing in AQL, as well as the dearth of type availability in ArangoDB in general. Is this a design decision related to not supporting data/database administration, or something to be added later to the roadmap?
It sounds like if you support write-intensive paths through the database, it would be considered an OLTP database for some OLTP workloads; do you publish TPC-C benchmarks anywhere? What about resource utilization?
Is there a particular reason to support JavaScript first? Is it because Swagger has JavaScript-first support, or a different reason?
To keep things simple and manageable, we originally started with AQL just being a language for querying the database. It was extended years ago to support data manipulation operations. I don't exclude the possibility that at some point it will support database administration or DDL commands, however, I am just one of the developers and not the product manager. And you are right about the main use case being OLTP workloads. For OLAP use cases, dedicated analytical databases (with fixed data schemas) are probably superior, because they can run much more specialized and streamlined operations on the data. To my best knowledge we never published any TPC benchmark results somewhere. I think it's possible to implement TPC-C even without SQL, however, implementing the full benchmark is a huge amount of work, so we never did...
Apart from that, ArangoDB comes with a JavaScript-enabled shell (arangosh) that can be used for scripting and automating database operations.
If you want to learn more about CQL: https://docs.scylladb.com/using-scylla/cql/
If you want to learn how it's different, here's a quick StackOverflow answer: https://stackoverflow.com/a/19140553/6995180
(Apologies for coming in sideways to this thread. Hat's off to ArangoDB, and all in the NoSQL arena who are pushing the envelope in terms of new Big Data solutions.)
For example, a specialized OLAP database which knows about the schema of the data can employ much more streamlined storage and query operators, so it should have a "natural" performance advantage.
However, a very specialized database may later lock you in to something, and in case you need something different, you will end up with running multiple different special-purpose databases.
Not saying this is necessarily bad (or good), but it is at least one aspect to consider how many different databases to you want to operate & manage in your stack.
Many search engines access data stored in JSON format. Hence integrating a search engine like ArangoSearch as an additional layer on top of the existing data models is no magic but makes a lot of sense. Allowing to combine models with search is then rather an obvious task for us.
Check out the SQL / AQL comparison page to get a quick overview: https://www.arangodb.com/why-arangodb/sql-aql-comparison/