In what development scenarios are Neo4j and other graph databases typically selected?

In what development scenarios are Neo4j and other graph databases typically selected?

I understand that graph databases, such as Neo4j, are structured with nodes and edges, and the data model used is referred to as a graph data model.

Common practical use cases for graph databases include fraud detection, social network bases (such as SNS), and recently, knowledge graphs and Graph RAG.

I have been working as a software engineer in Japan for about a year, starting with basic web applications and gradually transitioning to more complex, high-precision backend applications in the financial sector. However, I haven’t seen an architecture where "let's adopt a graph database" even once. It always seems like relational databases (RDBs) are naturally adopted, and I wonder if everyone is "RDB-minded."

Is this specific to Japan?

Now, I have some questions based on my hypothesis:

  1. Are there cases where graph databases are selected in the early stages of a product launch's architecture planning? Have you seen this before, and what kinds of scenarios does it apply to?
  2. My hypothesis is that initially, a relational database or traditional backend architecture might have issues (such as latency or excessive memory consumption), and graph databases are adopted as an update solution to address those issues.

I would appreciate your answers.

Best regards,
Shuzo

  1. You have all sorts of use cases for a Graph:
  • Any network type scenario (routing, mapping)
  • KYC (know your customer) and AML (anti money laundering)
  • EKG (Enterprise Knowledge Graph) - highly connected with semantics
  1. The most straightforward scenario as an example where SQL struggles is with "recursive" paths (imagine a simple person -manages-> person ... creating a simple organisational chart in RelationalDBs is complicated, whilst in a graph is super simple. Each database has pros/cons - Relational, NoSQL and Graph each have sweetspots.
1 Like