At the very beginning of most development endeavors lies an important question: 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. If you are one of those developers and you aren’t very familiar with in general, you’ve come to the right place! What database do I choose? graph databases 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. How Does a Graph Database Differ from a Relational Database? The main difference is the way relationships between entities are stored. In a graph database, relationships are stored at the individual record level, while a relational database uses predefined structures, a.k.a. table definitions. Relational databases are faster when handling huge numbers of records because the structure of the data is known ahead of time. This also leads to a smaller memory footprint. 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. The Graph Data Model First things first! To decide if you need a graph database, you need to be familiar with the basic terminology. The fundamental components of a graph database are: - the main entities in a graph. You can think of them as rows in a relational database. Nodes - the connections between those entities. These would be foreign keys in a relational database. Relationships - attributes that group similar nodes together. Labels - key/value pairs stored within nodes or relationships. Properties In a typical social network graph, the nodes represent people in different social groups and their connections with one another. Every person is represented with a node that’s labeled as Person. These nodes contain the properties , , and . The relationships between people in this network are of the type and contain a property to specify the duration of the friendship connection. Each person is assigned a location through relationships with nodes labeled . name gender location email FRIENDS_WITH yearsOfFriendship LIVES_IN Location While this is a very simple example, it concisely demonstrates the power and benefits of using a graph database. For example, if you wanted to add different properties to some of the nodes, you would be able to. 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. A property that was meant to be a string can be used as an integer without any constraints. To be fair, this can cause problems for you in the long run, but you can do it if need be. The Relational Data Model A relational database requires a predefined and carefully modeled set of tables. We create one for each entity and add the needed attributes as columns. While this is also pretty straightforward, it’s much more rigid than the graph schema and not as extendible. For example, each person is connected to other people through friendships, and to model this relationship, we have to add another table. If there were different kinds of connections ( , …) we would have to change the schema accordingly. 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. related to no longer friends When to use a Graph Database? There are always two sides to every story and graph databases aren’t a perfect solution for every problem. Far from it. 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. Here are three simple questions you can ask yourself to decide if there are any benefits to using a graph database. 1. Is my Data Highly-Connected? Graph solutions are focused on highly-connected data that comes with an intrinsic need for relationship analysis. If the connections within the data are not the primary focus and the data is of a , then a graph database is probably not the best fit. Sometimes it’s just important to store the data and complex analysis isn’t needed. transactional nature In our example, if we were to store only people without their relationships, then we would end up with a sparsely connected graph. Yes, a number of simpler graphs would remain because of the connections between nodes and , but this degree of connectedness and the consistency of the data structure is well suited for a relational database. Person Location 2. Is Retrieving the Data more Important to me than Storing it? Graph databases are optimized for data retrieval and if you choose one, then you should probably use this functionality often. If your focus is on writing to the database and you’re not concerned with analyzing the data, then a graph database wouldn’t be an appropriate solution. A good rule of thumb is, if you don’t intend to use in your queries, then a graph is not a must-have. JOIN operations In our example, if you only store data for the sake of interactions and you later on, then a graph database isn’t particularly helpful. However, if there are numerous connections within the data being stored, then a graph might be worth considering. logging don’t intend to analyze it 3. Does my Data Model Change Often? If your and demands frequent changes, then using a graph database might be the way to go. Because graph databases are more about the data itself than the schema structure, they allow a degree of flexibility. data model is inconsistent On the other hand, there are often benefits in having a predefined and consistent table that’s easy to understand. Developers are comfortable and used to relational databases and that fact cannot be downplayed. For example, if you are storing personal information such as names, dates of birth, locations… and don’t expect many new fields or a change in data types, relational databases are the go-to solution. On the other hand, a graph database could be useful if: additional attributes could be added at some point, not all entities will have all the attributes in the table and the attribute types are not strictly defined. In our example, the attributes and relationships of a person could be set in stone due to a specific use case and no further changes may be needed. When not to use a Graph Database 1. When Queries don’t Include Specific Starting Points If you need to run frequent for data that fits , a graph database wouldn’t be very helpful. Graph databases are well equipped to traverse relationships when you have a specific starting point or at least a set of points to start with (nodes with the same label). They are not suited for traversing the whole graph often. While it’s possible to run such queries, other storage solutions may be more optimized for such bulk scans. table scans and searches defined categories If the majority of the queries in our example include searches by property values over the entire network, then a graph database wouldn’t be the right fit. 2. When you Need Key/Value Storage Very often, databases are used to stored in . When you have a known key and need to retrieve the data associated with it, a graph database is not particularly useful. lookup information key/value pairs For example, if the sole purpose of your database is storing a user’s personal information and retrieving it by name or ID, then refrain from using a graph. But if there were other entities involved (visited locations for example), and a large number of connections is required to map them to users, then a graph database could bring performance benefits. A good rule of thumb is, if most of your queries return a single node via a simple identifier (key), then just skip graph databases. 3. When you Need to Store Large Chunks of Information If the entities in your model have like BLOBs, CLOBs, long texts… then graph databases aren’t the best solution. While you can store those objects as nodes and link them to other nodes to utilize the power of traversing relationships, sometimes it just makes more sense to store them directly with the entities they are connected to. very large attributes In our example, if each person had a long biography that needed to be included in the same database, a graph wouldn’t be the answer. However, if you needed to connect these biographies to other entities in the database (for example people that are mentioned in them), then the strengths of a graph database could outway the limitations. Is a Graph Database Worth it? It very much depends on your specific use case. Graph databases are a very powerful tool when it comes to handling interconnected data. If you have a hard time deciding, then go through the aforementioned requirements and check if any of them apply to your scenario. In this article, you have gained some insights into the fundamental differences between relational and graph databases. If you are still unsure if a graph database is the right choice for your project, then simply drop us a line on our , and we’ll be happy to help! community forum Also published at https://memgraph.com/blog/graph-database-vs-relational-database

Which Database Is Right For You?Graph Database vs. Relational Database

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

03/09/2018: Biggest Stories in the Cryptosphere

The Noonification: Immigrant Teens Are Working Dangerous Night Shifts in Factories (11/21/2022)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

10 Ways to Optimize Your Database

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

03/09/2018: Biggest Stories in the Cryptosphere

The Noonification: Immigrant Teens Are Working Dangerous Night Shifts in Factories (11/21/2022)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

10 Ways to Optimize Your Database

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps