Reliability of a Native Graph Database

Native Graph Database Offerings

Watch out for Jack of All Data implementations in database technologies. In building any technology there are always trade-offs when squeezing maximum performance out of the implementation so knowing what that guiding light is for a technology becomes very important. If you’re trying to do everything, or even too many things, odds are none if it will be great because you can’t go all out for one primary objective. Your focus will be split.

This becomes especially important when evaluating the graph database landscape where you have implementations that range from

• doing only edge caching or single hop queries by using focused indexing strategies
• to graph layers on top of existing database that still will suffer during complex graph traversals due to the underlying data storage implementation, which also restricts them from being able to guarantee the consistency of a relationship between two nodes on write
• to various hybrids such as combining document with graph that try to do it all, but ultimately end up doing neither well
• to fully native graph implementations that are designed for optimal graph traversal and navigation throughout the set of connected data

It’s key to understand these aspects of the underlying database implementation and the guiding light. Be wary of graph hybrids because they have a split focus on where they optimize. The saying, “Jack of all trades; master of none” isn’t just true for people. If a database tries to be a Jack of All Data types, it will be not be able to optimize for all of them. If you’ve been creating technology for any period of time you know the tradeoffs you make to do everything will result in none of it be as excellent as it could. I think this realization is why we’re seeing so many specialized data storage technologies that focus on doing that one thing really well.

Picking a fully native graph database offers granular control on operations from transactional behavior to data organization, to data consistency and reliability to cluster and driver protocols. With having maximum control over each graph database aspect, fine-tune graph traversal optimizations can be done. The sympathetic choices to graph principals for reliability and ACID transactional support can be accomplished and be carried out without any restriction.

For graph databases, reliability is a lot more important than availability since the data connectedness make them highly demanding than that of aggregate databases. The problem of having a graph over a current datastore will come down to how the data is being written and which record is true since in graph, there can be two available perspectives: node from each side.

If mutations are done via different requests at the same time, it can lead to an unpredictable relationship status. A non-native graph database tries resolve this issue through intricate algorithms, but it requires daily processing and often unsatisfactory results with erroneous data remaining.

This error can spread via the graph and other parts of your application that depend on relationships from a specific node perspective. If correct data is a priority, then it’s better off to go for a fully open source, index-free graph database such as that of ONgDB.

Open Native Graph Database (ONgDB) is an example of a native graph database that proves reliability, modeling, and transactional advantages as well as high clustering availability — keys for making reliable systems of today.

The focus of ONgDB is not split because they have chosen ACID compliance, referential integrity and graph traversal at scale for large graphs, which are all complimentary. Even though they are built on Lucene they haven’t tried to be a search server or a document store because these objectives would likely detract from the main objective of doing native graph traversal at scale very very well.

The main benefit of picking ONgDB as a native graph database is knowing that their guiding light is focused on graph traversal with consistent data and ACID compliant transactions. They’ve avoided a Jack of All Data approach. They have full control over enhancements and optimizations from top to bottom due to the complete control over the native graph database technology stack.

This focus is why we’ve seen the benefit of working with ONgDB as the primary contributor to the Graph Foundation and building the connected data + artificial intelligence tooling around ONgDB within the GraphGrid Connected Data Platform.