Traditional relational databases, the powerhouse of software applications since the 1980s, work well when your data is predictable and fits well into tables, columns, rows, and wherever queries are not very join-intensive.

But there are rich, connected domains all around us that relational software isn’t so well equipped at dealing with.

Relational database-management systems (RDBMS) only model data as a set of tables and columns, carrying out complex joins and self-joins when the dataset becomes more inter-related. Such queries are technically complex to construct and expensive to run. Plus, making them work in real time while end users wait is not easy, with performance faltering as the total dataset size increases.

(Related: NewSQL: Trying to solve what SQL and NoSQL can’t on their own)

Hence the rise of another type of database, optimized for connected data: the graph database. Graph databases are compelling because they enable companies to make sense of the masses of connected data that exist today.

Walking, not joining
Graph databases are very adept at working with not just single points of information, but also evolving relationship networks. It works particularly well when the relationships inside your data are important and your queries depend on exploring and exploiting them.

This is because graph databases store relationship information as a first-class entity. In addition, the flexibility of a graph database model allows you to add new nodes and relationships without compromising your existing network or expensively migrating your data. With data relationships at their center, graph databases are highly efficient when it comes to query performance, even for deep and complex queries.

One of the biggest differences between graph databases and relational databases is that the connections between nodes directly link in such a way that relating data becomes a simple matter of following connections. You avoid the join index lookup performance problem by specifying connections at insert time, so that the data graph can be walked rather than calculated at query time.

This property, only found in native graph databases, is known as index-free adjacency, and it allows queries to traverse millions of nodes per second, offering response times that are several orders of magnitude faster than with relational databases for connected queries (e.g., friend-of-friend/shortest path).

Model, store and query complex customer data
So does it make sense for CIOs to use both relational databases and graph databases? Or should they standardize across the enterprise on one or the other? Today it makes pragmatic sense to use both. Each model has their pros and cons; as the enterprise IT user typically has a wide set of problems it needs to solve, there is no single database or database model that is best at everything.

Actually understanding which databases to use is becoming an important skill. The most common current applications for graph databases include fraud detection, real-time recommendation engines, master data management, network and IT operations, and identity and access management. But a graph database makes sense for any organization seeking to make the most of its connected data.

How to choose
However, that’s not a very rigorous approach to delineating which is best. How can you tell when the situation is right for graph databases over RDBMS? Start by drawing the domain on a whiteboard. If your domain entities have relationships to other entities, and your queries rely on exploring those relationships, then a graph database is a great fit.

Developers find the whiteboard test very convenient to work with because of its adaptability. This ability to adapt is particularly useful as new information about the domain becomes known or changes in requirements cause the model to change.

Existing deployments are also potential candidates for introducing graph databases, of course. Again, this is because graph databases can really help improve or even dissolve performance and scaling problems caused by joins. While graph databases can support transactional data with ACID guarantees, data warehouse systems and offline analytical workloads can also be moved into a real-time environment using graph database.

What can go wrong?
What are the biggest drawbacks to using graph databases? The number of graph databases available is growing, which is good news for the developer, but one thing to be aware of is that the technology is still fairly new compared to relational software, which has now existed for a full generation. It takes time to build a solid database market after all, regardless of data model.

Transactions, recovery and durability are features that you would take for granted when a database may not be working as expected—or worse, not be present at all. And as many graph database implementations are still young, it may be a good idea to first verify that core features work as advertised.

Another thing to be aware of is that some graph databases only offer the graph model, but the underlying implementation is backed by a traditional, relational or other type of NoSQL database. That can impact runtime behavior as queries may get translated into joins. Be clear about what you are getting.

Start building the skills to give you development options
To conclude, it’s worth knowing that developing skills to enable your team to know when to choose graph vs. relational will start to matter more and more. This year will see an increase in new entrants into the graph database space and an increase in the size of the overall market for graph databases. Over time, most likely, graph databases will become as commonplace as relational databases are today.

Allied to this is the rise of graph data query languages like Cypher, which was recently made available through the openCypher project. Many graph insiders expect Cypher to become the standard language that allows graph databases to be searched, regardless of the product involved, which will power strong growth for the entire market.

My advice is to start trialing graphs, as the investment required to find out if your organization can benefit from using graph databases is quite small—but the potential ROI can be surprisingly high.

Graph vs. relational? A few years ago, you probably didn’t consider that a serious question. Now it is, so you need to start finding your own answer.