Relational databases like Oracle still dominate revenue. MongoDB dominates adoption. And Cassandra dominates scale.
So, what does that leave the graph database?
Though graph databases don’t get as much press as their document and columnar-style peers, they fill a useful role within the enterprise. By giving developers a way to express relationships between data rather than fixating on the data itself, graph databases offer a powerful new way to tame the growing complexity of big data.
To better understand graph databases and how they fit into the broader database market, I sat down with Luca Olivari, my former MongoDB colleague and CEO of OrientDB, a leading multi-model database that spans graph, document, and relational databases.
TechRepublic: What are graph databases and how do they differ from other NoSQL databases like MongoDB (document), Cassandra (wide column), etc.?
Olivari: Graph databases are optimized for managing highly related data and complex queries. Focus is on the relationships rather than the data itself. A graph database stores persistent direct links (joins, if you will) that can be queried efficiently, and response times are independent of the total size of the dataset.
Document databases are a great fit to manage complex and ever changing data, but they lack functionalities to relate documents and model relationships. Likewise, wide column stores are scalable, but they don’t provide features to connect data. On the other hand, relational databases compute relationships at run time, and response time increases with the size of the dataset.
TechRepublic: Speaking of document databases, you spent some time at MongoDB. What led you to leave MongoDB for OrientDB?
Olivari: I have fond memories of my time at MongoDB and learned a lot building the international business with the experienced management team there.
That said, my choices are always based on three basic variables: Products, People, and Market Opportunity. I’ve always been intrigued by OrientDB as a product, as it solves some of the problems that people are facing when using MongoDB and first-generation NoSQL products.
OrientDB allows you to connect JSON documents using direct links taken from the graph theory. Furthermore, it makes it easy to adapt legacy applications that are using SQL. It’s schema-full, schema-less or hybrid, and it supports ACID transactions. That creates a huge market opportunity, and we have a talented team to go after it.
TechRepublic: What’s a typical use case for OrientDB? That is, when would you be a fool not to use a graph database for a particular business need?
Olivari: Relationships are as important as the data itself in today’s connected world. Use cases that require modeling complex relationships are the best for graph databases. As such, Real Time Recommendation, Fraud Detection, Master Data Management, Social Networks, Network Management, Geolocalized Apps and Routing, Blockchain, Internet of Things, Identity Management, and many others come to mind.
TechRepublic: You used the word “multi-model.” Is it this aspect of OrientDB, or something else, that sets OrientDB apart among graph databases like Neo4j?
Olivari: OrientDB is a distributed graph database where every vertex and edge is a JSON document. In other words, OrientDB is a native multi-model database and marries the connectedness of graphs, the agility of documents, and the familiar SQL dialect.
The combination of graphs and documents simplifies the architecture, removing the need to keep multiple databases synchronized, and the SQL dialect reduces the learning curve when moving from legacy relational products to next generation databases.
TechRepublic: So, you’re not a vanilla graph database at all. Will a graph database ever have the same adoption as a document database like MongoDB or a columnar database like Cassandra? Or are graph databases suited for a smaller universe of potential applications?
Olivari: The addressable market for pure graph databases is relatively smaller, but we’re by no means talking about a small one. Forrester Research estimates that graph databases will reach over 25% of all enterprises by 2017, and that represents a multi-billion dollar market opportunity.
PwC technology forecast defines graph databases as “The least mature NoSQL type, but the most promising,” and I tend to agree. Adopting graph database can give a competitive advantage to data-driven organizations. The value that graphs can bring to companies is not widely known yet, but that’s the fastest growing category, according to db-engines.
OrientDB is the leading multi-model database, and our addressable market includes document, graph, and relational.
TechRepublic: Back to graph databases. Should we be thinking about how graph databases complement other databases? In fact, is this how we should be thinking about modern data: that there is no one right database for every need, and so developers should always look to apply the right database tool to a particular business need?
Olivari: We often hear the term “polyglot persistence,” which means using multiple databases to solve different problems. That’s a side effect of NoSQL products that are addressing only a subset of the data management issues.
Using a polyglot approach is not always the best choice, as it forces developers to support more than one database and synchronize them to satisfy their requirements.
There will always be databases that solve a niche problem extremely well, but we need a solution to become the operational datastore of the modern enterprise. Multi-model databases, in general, and OrientDB, in particular, have what it takes to become a viable alternative to RDBMS and succeed first generation NoSQL products.