DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 967,611 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for What on earth are graph databases?
Ammar Raneez
Ammar Raneez

Posted on

What on earth are graph databases?

You might have heard about SQL and NoSQL databases (they are, after all, the most popular available), but have you heard about a Graph Database? πŸ€”

Let us look closer into this and explore why you should consider this novel approach.


When we talk about Graphs, we’re talking about very densely connected data with many relationships (Ex: Social network connections and recommendation engines). A graph database is simply a form of the infamous graph data structure almost always questioned during technical interviews.

Graph databases store β€œnodes” and β€œrelationships” instead of tables and documents.

Imagine sketching ideas on a whiteboard and joining them together forming some kind of mind map. You have the flexibility of thinking about how you would use it. Graph databases have the same influence β€” that data is stored similar to how your mind map would look like; densely connected relationships, albeit not having a strict predefined model to follow.


Why Graph databases?

Why would we need to use a graph database? After all, almost all applications that we build use either an SQL or NoSQL database.

The most important reason is that it makes the reasoning of data much more understandable β€” especially when the data is densely connected.


As the complexity increases, the requirement to use a graph database also increases

Simply displaying an image that shows why to use a graph database will not suffice, hence, I will compare a simple use case using actual code.


Imagine this scenario this SQL:

SQL-design

Our goal is to find the name of companies that purchased the product β€œMac”.

A solution would be as follows:

SELECT distinct c.CompanyName
  FROM customers AS C
  JOIN orders AS o ON (c.CustomerID = o.CustomerID)
  JOIN orderdetails AS od ON (o.OrderID = od.OrderID)
  JOIN products as p ON (od.ProductID = p.ProductID)
  WHERE p.ProductName = β€˜Mac’
Enter fullscreen mode Exit fullscreen mode

It obviously is pretty straightforward, however, when we put this exact same scenario into a graph database, things start getting more understandable.


The exact same scenario in a Graph Database design:

graph-db-design

The design, in this case, is easier to read and understand since the thought process required to build proper models is not present.

A solution, using Gremlin is as follows:

g.V().hasLabel(β€˜Product’).has(β€˜productName’, β€˜Mac’)
  .in(β€˜HAS_PRODUCT’)
  .in(β€˜HAS_DETAILS’)
  .in(β€˜PURCHASED’)
  .values(β€˜CompanyName’).dedup()
Enter fullscreen mode Exit fullscreen mode

Querying, in this case, is much simpler since all you require to do is traverse the graph without having to worry about joins.


Popular Graph Databases

Currently in the industry there are a couple of popular options of graph databases, some of which are:

  • Neo4j β€” an ACID-compliant transactional database with native graph storage and processing.
  • ArangoDB β€”a scalable, fully managed graph database, document store and search engine in one place.
  • Amazon Neptune β€” a fast, reliable, fully managed graph database service

All in all, graph databases can be an excellent solution if you require highly connected data with a large number of relationships β€” although this topic by itself can be daunting since it requires knowledge of how the graph data structure works.

Keep growing! 😁

Top comments (0)

🌚 Life is too short to browse without dark mode