OrientDB: New GraphDB Engine in Beta

Kudos on developing such a great API! I always point out to the Blueprints stack as an example of tastefully designed, masterfully layered API design.

Obligatory Python adapter for Blueprint-conforming databases: http://bulbflow.com/overview/

Anyone have experience with this? Looks fun.

Neo4J is a pure GraphDB with a good level of maturity and support, but lacks on scalability in comparison to OrientDB (that offers a multi-master approach) and Titan (based on HBase/Cassandra). I think Titan (that is the most recent) is a good choice if you've many servers and huge parallel workload.

Furthermore Neo4J has a dual license model and the high-available is pretty costly (http://www.neotechnology.com/price-list/) while OrientDB and Titan are both released under the Apache License (=commercial friendly). About the model even though all these products supports the same interface (Blueprints) OrientDB is more flexible allowing sub-types for Edges and Vertices where to apply constraints.

My 0,02. Lvc@

Titan is to Neo4j, as Cassandra is to SQLite.

Addition to what lvca (the author himself :) ) said, Unlike other pure GraphDB's, OrientDB is a hybrid DB, ie. under-the-hood its a document DB, so you will get best of both (if you want).

Why the name?

(Get the website spell checked and grammar checked by a native English speaker)

Great work, lvca ! I'm especially happy about the the 'edge label -> subclass' optimisation, as it is a fairly common use case of mine.

Wish you all success.

Have you tried benchmarking against the competition? I would be interested in seeing the performance advantages and disadvantages.

I want a graph that keeps an order on the edges, e.g., (A, B, C) being nodes, the graph {(A,B), (A,C), (A,C)} differs from the graph {(A,C), (A,B), (A,C)}. In other words, the outgoing edges are a list, not a set. Where can I find discussion of how to do that efficiently?