NoSQL · Data models beyond tables
When should you use a graph database?
Short answer
Use a graph database when relationships are the main query, especially multi-hop traversals and variable-depth paths. It stores edges as first-class records, so traversal does not require repeated joins.
The model has nodes, relationships and properties on both. Relationships have a type and direction, which makes the domain semantics explicit. Index-free adjacency means a node holds direct references to its edges, so following a relationship is cheap rather than a global lookup.
MATCH (u:User {id: $userId})-[:FOLLOWS*1..3]->(other:User)
WHERE NOT (u)-[:FOLLOWS]->(other)
RETURN other.name, count(*) AS paths
ORDER BY paths DESC
LIMIT 20;Good and bad fits
- Good: fraud rings, recommendation paths, access-control graphs, network topology
- Good: queries whose depth is not known in advance
- Bad: high-volume append-only events with simple key lookups
- Bad: large aggregate scans that do not care about relationships
Traversal cost grows with the size of the neighbourhood you touch, not with the total database size. That is the key advantage. A supernode with millions of edges breaks that intuition, because one hop can explode into a huge fan-out.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is a supernode and why is it a problem?
- 2How does index-free adjacency change traversal cost?
- 3Would you use a graph database for a social feed?
- 4How do you model a relationship that has its own properties?
Say it in the interview
I reach for a graph database when the relationship is the query, particularly when traversal depth varies and joins would explode. Nodes and edges are stored directly, so following a relationship does not require a global index lookup. The cost scales with the neighbourhood you touch, which is great until a supernode fans out to millions of edges. For simple one-hop lookups or heavy aggregate reporting, I would stay with a relational or document store.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.