Disclaimer: I'm part of the ArangoDB team. As written in the post the whole benchmark is open source. The idea is that you can run it on your own. Also, pull requests are welcome. If you think it's marketing spam, take the chance and improve the configuration. We will publish an update of the post.
Disclaimer: I'm part of the ArangoDB team. As written in the post the whole benchmark is open source. the idea is that you can run it on your own. Take the chance and get your own impression.
Disclaimer: I'm part of the ArangoDB team. As written in the post the whole benchmark is open source, and you are welcome to add other DBs. That is appreciated. It is just important that there is an official node.js driver and a GA version will be used.
(Discmlaimer: I'm the CEO of ArangoDB)
Glad to announce Florian Leibert (CEO of Mesosphere) and Luca Olivari (former Executive at Oracle and MongoDB) as part of our ArangoDB family. Warm welcome! Together with their advise and expertise we will further sharpen our focus and accelerate our growth.
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.
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.
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.
Claudius from ArangoDB here. Frank already answered a question about realtime queries below: "We are evaluating various possibilities, how to implement streaming queries in an efficient and scalable way. For instance, are restrictions to the general AQL necessary for such queries to be able to scale? Stay tuned."
You are right that that is not required. That ArangoDB speaks HTTP doesn't mean it has to be exposed to the browser.
You can use Foxx to host your entire server-side application inside ArangoDB in some cases but in our experience, the best approach is having a middleground where the data-intensive server-side code lives in Foxx services and the client-facing part (e.g. server-side rendering) exists outside of it.
Foxx offers you the option to put backend logic directly inside the database; it's not an all-or-nothing decision.
Saying Foxx is like stored procedures is overly simplistic.
ArangoDB's external API is the HTTP API. Foxx lets you extend that HTTP API with arbitrary code that will be executed in V8 with direct access to the same native APIs it uses internally.
The closest equivalents I'm aware of are RethinkDB's Horizon (which isn't hosted in the database) and CouchDB's CouchApps (which are far more limited in what they can do).
You can think of it as having a subset of Node.js running right on top of the database with direct memory access and scaling (Foxx services run on each coordinator).
I'm Claudius, author of the tests. I've been asked to include a lot of different databases into the test runs. The most requested databases were Postgres/JSON and RethinkDB. I started with Postgres. The Postgres manual states that JSONB might be faster, but some StackOverflow answers indicate that it takes more space than JSON, while JSON might be slightly more compatible with legacy code. I've shown the queries and setup to some local Postgres users. They did not point that JSONB will be much faster for the kinds of requests used in the test setup. For instance, we do not use special indexes apart from the primary one by choice.
I wanted to move on to RethinkDB next, but I see your point that a comparison between the different JSON formats of Postgres can also be very enlightening. This should replace guessing with hard facts. As always I will update the blog post and add this tests as well - as we did in the past, see https://www.arangodb.com/nosql-performance-blog-series/.
If you have any improvements concerning the configuration of Postgres or SQL queries, I'm will be more than happy to include them as well in the update. I will push the used configuration to GITHUB as well.
We are a multi-model database, which is not in a strict sense a competitor but is competing with Neo4J in some areas. Therefore I'm definitely not a Neo4J expert. However, I'm now working in the field for over 15 years, developing in-memory solutions, databases and application servers. Developing ArangoDB for almost three years and I have talked to a lot of people in that area and to people who are using Neo4J. There are always obstacle when moving to new products. But most of the people who I met are quite happy with Neo4J.
I'm Claudius, the author of the blog post. The intent of the blog was not to show, that a particular product is not performing well. There are thousands of different use cases and each database has its strengths and weaknesses. For a different scenario the results might be different. Neo4J is a solid product and is doing a good job. The aim of the blog was to show, that multi-model can compete with specialized solutions. What I wanted to show, is that a multi-model approach per se does not carry a performance penalty.