Johan Svensson, CTO of Neo Technology, interviewed by Minda Zetlin for The Enterprisers Project
The Enterprisers Project (TEP): Can you explain why graph databases are compelling? How do they differ from traditional databases?
Svensson: Yes, I would love to. Graph databases are compelling because they enable companies to make sense of the masses of connected data that exist today. Traditional relational databases have been the power-horse of software applications since the 80s. They work fine when your data is predictable and fits well into tables, columns and rows and where queries are not very join intensive. But this is a problem, because in the real world, there are no isolated pieces of information. There are rich, connected domains all around us.
Graph databases, on the other hand, work wonderfully 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.
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 incredibly efficient when it comes to query speeds, even for deep and complex queries.
TEP: Some very large enterprises are now using this technology. Why is that?
Svensson: I think the number one reason why companies are increasingly using graph databases is because it allows them to gather insights that were previously unavailable. This gives them a competitive advantage as they can make better decisions and give their customers better service. More and more businesses are realizing that in order to succeed in a highly connected world, they must leverage the connections within their data for all they’re worth — but they need the right technology to do so.
TEP: Does it make sense for companies to use both relational databases and graph databases or should they standardize enterprise-wide on one or the other?
Svensson: Today it makes sense to use both, because different models have their pros and cons. The enterprise typically has a wide set of problems it needs to solve, and there is no single database or database model that is absolutely best at everything. Just knowing which databases to use is becoming an important skill.
TEP: So then how can you tell when the situation is right for graph databases?
Svensson: 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.
This especially applies to new projects as developers find the model very convenient to work with, in part also 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. Again this is because graph databases can alleviate performance and scaling problems caused by joins. Data warehouse systems and offline analytical workload can sometimes even be moved into a real-time environment using graph databases.
TEP: Are there certain types of software for which graph databases are most useful?
Svensson: The most common applications for graph databases include fraud detection, real-time recommendation engines, master data management (MDM), network and IT operations, and identity and access management (IAM). But really, a graph database makes sense for any organization seeking to make the most of its connected data.