...Neo4j has cornered the market... In truth there aren't many alternatives out there, but alternatives exist. OrientDB is a hybrid graph document database that offers the unique flexibility of modeling data in the form of either documents, or graphs, while incorporating object-oriented programming as a way of encapsulating relationships. Again, it's a great example of developers imagining ways in which we can accommodate the myriad of different data types, and relationships that connect it all together.

New technologies such as the MVRB-tree algorithm implemented in the OrientDB graph database have proved far more efficient and scalable than the traditional relational data base management system...

I narrowed my choices to OrientDB and Neo4j. It’s been a couple years since that decision process occurred, but I distinctly remember a few reasons why I ultimately chose OrientDB over Neo4j: Performance benchmarks for OrientDB were very impressive, The OrientDB development team was very active, Cost: OrientDB is free. Neo4j cost more than what I was willing to pay or what I could afford. I forget which it was...

I am glad we didn’t have a learn some aliens language like Cypher to traverse and find patterns out of the relationships. It has a simple SQL like language to do the stuff we needed. This same was very difficult and painful to do using BigTable like DBMSs e.g. HyperTable and HBase. Obviously we are not talking about hundreds of petabytes of data here. While MongoDB was notorious about data lose, because of its late data flushing out to disk. So we tried CouchDB, but we very disappointed to see how we had to query data using its improperly implemented Map-Reduce querying feature. Neo4J is a good product to drain out your money and still keep you unsatisfied, due to its non-distributed nature. So we were left with OrientDB as the single and the best choice for our problems solution.

As a result our DNS server was able to move to a model that keeps almost every zone in memory while serving the data out of a lock-free pipeline. This yielded significant performance improvement that resulted in a >7x QPS processing capacity on a per DNS server basis.

We have chosen OrientDB because we needed a Graph database to manage relationships among documents in a simple ed efficient way. Furthermore we needed an embeddable engine with a non-limiting license due to our business model. OrientDB matches all our criteria and over. Its team is always available, very active and always ready to give support about doubts and questions.

OrientDB appealed to us because of its flexibility and performances. Creating mixed schema data structures suits our needs. Traverse operations and fetch strategies are extremely efficient and easy to use. Last but not least, we speed up the coding phase comparing with a traditional RDBMS approach. In short, a Five Star Product.

...Which brings me back to OrientDB: when you have multiple processes and multiple people undertaking multiple tasks against multiple data sources, then doing things like impact analysis (which Axon supports) can get quite complex. Without a graph capability of some kind it can easily become too difficult and slow to explore the environment.

I really appreciate to use OrientDB, due to the point, that it can be integrated very easily and that it is written in Java. Moreover, user defined databases can be created on-the-fly. Great. A big benefit is, that the configuration can be hidden from the user. Which user wants to setup a MySQL or MongoDB previously? Furthermore, my users most commonly don't have the capabilities to do that.