ArangoDB Closes 2.2M Euro Investment Led by Target Partners

ArangoDB is a multi model store, which is to say it lets you store key value pairs, json documents, and graphs. (Edges are just another document with two special fields: "_from" and "_to".

My team just spent 3 weeks investigating document stores and ultimately settled on arangoDB because: 1. Graph functionality, 2. Read after write consistency, 3. Partial updates, 4. Efficient joins across shards, 5. The (limited) text search features, 6. AQL is just pretty sweet. There was a whole spreadsheet matrix but that's what I can remember without pulling it up.

We really liked RethinkDB for its change feeds. We are probably going to use Elastic for search, because we want to expose Lucene to our users, so we'll probably have to write some foxx endpoints to manage the data replication. I like the idea of foxx but really hate that it's JavaScript based. I'm planning on looking into using ScalaJS if possible.

I have not used Arango in production although I evaluated it and exchanged a few emails with Claudius.

I see a number of reasons why ArangoDB might be more interesting than Rethink:

1) Arango is a multi model database with graph, noSQL, and key-value pairs. Even if Rethink has joins and complex queries, it will never be as flexible for general data modelling.

2) Foxx is a logical layer on top of the database. While it's limited compared to a classic server side application it offers way more flexibility than Rethink could ever.

3) Arango (or Foxx) don't offer realtime data like Rethink or Firebase, but quite frankly there are few cases where such feature is needed.

On our project we are probably going to use DreamFactory instead of Arango because we are more comfortable with SQL dbs and it has a number of other valuable features over Arango.

I'm an ArangoDB team member. We are starting with our own Jepsen tests. But we will ask Aphyr as soon as possible to do an official test. In the meantime can the community check our implementation.

Jepsen tests are basically a closure framework to conduct such tests. We took some of the existing test cases and rewrote them for ArangoDB. So these are not "official Jepsen tests" but tests we did ourselves to track down issues. If you want to inspect and retest yourself, that will be possible. There's no reason to keep the tests closed source. Of course it would be great to get ArangoDB Aphyr-approved eventually.

There's a general comparison on our website: https://www.arangodb.com/why-arangodb/arangodb-vs-mongodb/

One major difference is that ArangoDB has full support of transactions across collections. Also while MongoDB now has limited graph functionality, ArangoDB is actually optimized for graph queries and can do arbitrary traversals and joins very efficiently.

The problem with Gremlin/OpenCypher is that they are primarily designed as graph query languages. ArangoDB takes a multi-model approach and many ArangoDB users focus on documents first and add in graph queries as an optimization step as their products mature. AQL is designed to be very easy to learn and mixes the document and graph paradigms seamlessly, embracing the multi-model nature of the database.

Personally I think that starting with a blank slate was the right choice compared to other multi-model databases that have found it necessary to extend a subset of a standard query language with their own proprietary additions to achieve the same goals.

I'm an ArangoDB team member.

We did a benchmark that shows you the performance regarding Neo4J. Before you shout that it made by us have a look, please. It's all open source. The data, the scripts and so on. Everything we use for it, we described in detail.

AQL is much more than a graph query language; therefore, Gremlin and OpenCypher aren't alternatives.

What is it that worried you? That the team is going to check things over to make sure that they have things done right?

The only alternative to that is to just kind of pretend that it all works without doing the hard work to verify. You saw how that ended up for a lot of other systems that Kyle has tested.

It takes time and money for an open-source DB to become established. I think Arango is taking the right steps and this investment will help a lot in getting there.

PS: I only started using ArangoDB recently for the first time on a client project and it was refreshing to say the least. Being able to do complex joins, coming from a Mongo environment feels so much better.

I use RethinkDB and I don't feel screwed. It still works great and has a future in open source land. I don't see what the big deal is.

You can active the dev mode for a Foxx app. This way any change will be directly visible without the need of replace.

We're watching node's support for the webkit developer tools closely but as their recent releases show, integrating with external debugging tools is difficult because V8 is always a moving target. There are also architectural differences that make it more difficult to offer debugging capabilities in Foxx, such as node being typically run as a single process whereas a typical ArangoDB installation will use any number of parallel V8 threads and incoming requests being load balanced accordingly.

We're constantly trying to improve the developer experience of Foxx, though, and the partial rewrite of Foxx for ArangoDB 3.0 was a big part of that, hopefully reducing the need for debugging by making the API easier to reason about.

During development I would recommend trying out the development mode and syncing your changes to the deployed service on the file system. For debugging queries it can also be helpful to run them from the web interface first and then use `aql` template strings in JavaScript instead of constructing the queries piece by piece.

We are closely monitoring the development. Not being a Java database, we cannot run Java queries natively. Tinkerpop3 has added some hooks for non-Java, but it would still very hard to get the speed of AQL. But I hope that Tinkerpop will open up to non-Java even more.

I'm an ArangoDB team member. The new graphLookup is far away to be a graph functionality. It's only a recursive lookup. Yes, the storage is special. The three data models are combined in one database core.