Okay, I like how backwards compatibility is preserved. I worked with mongoDB at my previous company and we ended up not being able to migrate to mongoDB 3.x. I think it was because we forked 'eve-mongoengine' and couldn't merge upstream changes, which ended up forcing us to version the entire stack through the database at the same time, which passed the threshold of feasibility.
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?
ArangoDB is a schema-less database.
There is currently no support for schemas or schema validation on the database core level, but it may be added later, because IMHO it is a very sensible feature.
When that is in place, AQL may also be extended to get more strict about the types used in queries. However, IMHO that should only be enforced if there is a schema present.
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...
Forgot to answer the JavaScript question...
JavaScript can be used in ArangoDB to run something like stored procedures. ArangoDB comes with a JavaScript-based framework (named Foxx) for building data-centric micro services. Its usage is completely optional however. When using the framework, it will allow you to easily write custom REST APIs for certain database operations. The API description is consumable via Swagger too, so API documentation and discoverability are no-brainers.
Apart from that, ArangoDB comes with a JavaScript-enabled shell (arangosh) that can be used for scripting and automating database operations.
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?