There are a lot of use cases for which you should stick with relational databases or maybe search for other alternatives aside from graph databases. There are always two sides to every story and graph databases aren’t a perfect solution for every problem. A relational database isn’t suited for this specific use case because the focus isn’t on the data itself but rather on the relationships within it. If there were different kinds of connections ( related to, no longer friends…) we would have to change the schema accordingly. While this is also pretty straightforward, it’s much more rigid than the graph schema and not as extendible.įor example, each person is connected to other people through friendships, and to model this relationship, we have to add another table. We create one for each entity and add the needed attributes as columns. The Relational Data ModelĪ relational database requires a predefined and carefully modeled set of tables. To be fair, this can cause problems for you in the long run, but you can do it if need be. A property that was meant to be a string can be used as an integer without any constraints. Unlike a table, where you need to add a column for each additional attribute, here you can be much more flexible with the data structure and types. For example, if you wanted to add different properties to some of the nodes, you would be able to. While this is a very simple example, it concisely demonstrates the power and benefits of using a graph database. The relationships between people in this network are of the type FRIENDS_WITH and contain a yearsOfFriendship property to specify the duration of the friendship connection.Įach person is assigned a location through :LIVES_IN relationships with nodes labeled Location. These nodes contain the properties name, gender, location and email. Every person is represented with a node that’s labeled as Person. In a typical social network graph, the nodes represent people in different social groups and their connections with one another. Properties - key/value pairs stored within nodes or relationships.Labels - attributes that group similar nodes together.These would be foreign keys in a relational database. Relationships - the connections between those entities.You can think of them as rows in a relational database. The fundamental components of a graph database are: The Graph Data Modelįirst things first! To decide if you need a graph database, you need to be familiar with the basic terminology. Graph databases don’t have a predefined structure for the data which is why each record has to be examined individually during a query to determine the structure of the data.
This also leads to a smaller memory footprint. Relational databases are faster when handling huge numbers of records because the structure of the data is known ahead of time. In a graph database, relationships are stored at the individual record level, while a relational database uses predefined structures, a.k.a. The main difference is the way relationships between entities are stored. How Does a Graph Database Differ from a Relational Database? In this article, you will learn about the main differences between a graph database and a relational database, what kind of use-cases are best suited for each database type, and what are their strengths and weaknesses. If you are one of those developers and you aren’t very familiar with graph databases in general, you’ve come to the right place! At the very beginning of most development endeavors lies an important question: Which database to choose? There is such an abundance of database technologies at this moment, it’s no wonder many developers don’t have the time or energy to research new ones.