Graph Databases
First-class nodes and edges. Index-free adjacency and graph query languages.
Level: intermediate
What is it?
A graph database represents entities as nodes and their relationships as edges, often with properties on both. It is designed for traversals and queries where relationship structure is central rather than incidental.
Why does it matter?
Relational joins can become complex for variable-depth relationships, such as social connections, network dependencies, or fraud rings. Graph storage/query models make traversals more natural, but do not automatically outperform relational databases for every workload.
Mental model
The main question is often who is connected to whom and how. Start from a node, follow edge types and direction, and constrain traversal depth and predicates.
How it works
- Nodes represent entities; edges represent directed or undirected relationships according to the model.
- Properties can annotate nodes and edges, while labels/types constrain traversal and indexing.
- Index-free adjacency is an implementation concept in some graph systems, not a universal performance guarantee for all graph databases.
- Traversal cost depends on degree distribution, path depth, filtering, and data placement.
- Some workloads are better expressed as SQL joins or recursive queries; choose by access pattern and operational requirements.
Steps
- Identify the entities and relationships the application must query.
- Choose node/edge types, direction, properties, and uniqueness constraints.
- Create indexes for the entry points used by queries.
- Bound traversals and inspect performance on highly connected nodes as well as typical data.
Real-world usage
- Recommendation graphs, dependency maps, identity relationships, and path analysis.
- Queries involving multi-hop relationships or variable-depth paths.
Common mistakes
- Assuming a graph database is automatically faster for every connected-data problem.
- Allowing unbounded traversals over hubs with huge degree.
- Failing to model edge direction and relationship semantics carefully.
Interview questions
When might a graph database be a good choice?
When central queries traverse variable-depth or dense relationships and the graph model expresses those operations naturally.
What can make graph traversals expensive?
Large branching factors, deep paths, poor entry-point selectivity, and distributed data movement can cause huge traversal work.