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.

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.

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.

...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.

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.

OrientDB’s design proved to be the perfect compliment to our platform. OrientDB saved us countless time in providing critical features for our platform that more traditional database technologies do not deliver. it did so in a well-designed, easy-to-integrate approach.

Before we selected OrientDB we developed a few prototypes to evaluate the performance of the database in being able to efficiently handle large volumes of records of data where the precise field composition of each record is specified by the user during deployment. We evaluated both relational databases and a couple of NoSQL database and OrientDB was clearly the best option. The flexible Apache license was also another key reason why we made the selection. Finally, the fact that OrientDB is supported by such a dedicated group of people who also provide commercial support if needed, was the feature that closed the deal.

OrientDB had all the features that we needed to tackle the challenge in the agreed time limit. There was no need to learn a new query language since it supports SQL and the Studio Graph View is great for exploratory analysis.

Simply, if you are open source, then Neo4j is open source; if you are closed source, then Neo4j is commercial. The choice of license is a choice in what you will do with Neo4j. If you incorporate Neo4j in a closed, proprietary project, then you require a commercial license. Importantly, it does not matter whether or how you will profit from using Neo4j

Once we began using OrientDB and working with graphs, our algorithms were 2.5 times faster!

The main selection criteria were: language on which DBMS was developed, License, Graph model, API, query languages, Consistency, scalability.

Compared to the original use of Oracle & MySQL, our decision-making time decreases from the original 30 seconds to 1 second, 30 times performance increase, and improves fraud catch rate by 20%.

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.

OrientDB can do in milliseconds what our RDBMS could never do. With it, we are much more effective at catching fraudulent activity in real time.