A graph database is a database that stores data as nodes connected by relationships, both of which can carry properties, and that answers queries by traversing those connections directly instead of computing joins. Among database models, it is the choice for data whose value lies mainly in how entities are connected.
Typical domains include social networks, fraud rings, supply chains, access permissions and knowledge graphs. Where a relational system struggles with queries such as “friends of friends within four steps”, a graph database keeps traversal cost proportional to the part of the graph visited, not to the total size of the data.
How a graph database stores and traverses data
The most common model is the labeled property graph. Nodes represent entities and carry labels such as Person or Account; relationships are directed, typed edges such as OWNS or TRANSFERRED_TO; and both hold key-value properties. Relationships are stored as first-class records, not inferred from matching keys.
Many engines implement index-free adjacency: each node record points directly to its relationships, so moving from one node to its neighbors is a pointer lookup rather than an index search. Indexes are still used, but mainly to find the starting nodes of a traversal.
| Element | Represents | Example |
|---|---|---|
| Node | An entity | A customer, a device, a bank account |
| Label | The type or role of a node | Person, Account, Product |
| Relationship | A directed, typed connection | PURCHASED, FOLLOWS, LOGGED_IN_FROM |
| Property | An attribute on a node or relationship | Name, amount, timestamp |
| Path | A sequence of connected nodes | Customer to device to another customer |
Graph models and query languages
Two data models dominate. Property graphs favor application data and traversal queries, while RDF triple stores represent facts as subject-predicate-object triples and support ontologies and reasoning. The query languages follow from the model.
| Language | Model | Style | Status |
|---|---|---|---|
| Cypher and openCypher | Property graph | Declarative ASCII-art patterns | Widely implemented |
| GQL | Property graph | Declarative patterns | ISO standard published in 2024 |
| SQL/PGQ | Property graph over tables | Graph patterns inside SQL | Part of SQL:2023 |
| Gremlin | Property graph | Imperative step-by-step traversal | Apache TinkerPop |
| SPARQL | RDF triples | Declarative triple patterns | W3C recommendation |
A Cypher pattern such as (a:Person)-[:FOLLOWS*1..3]->(b:Person) expresses a variable-length path of one to three hops in one line, which in SQL would require a recursive common table expression or several self-joins.
Graph databases compared with other models
Each database model optimizes a different access pattern. A graph database is strongest when queries follow many relationships of varying depth, and weakest for large aggregations over flat records.
| Model | Core unit | Strongest at | Weak at |
|---|---|---|---|
| Graph database | Nodes and relationships | Multi-hop traversals, path finding | Full-table aggregations |
| Relational database | Rows in tables | Transactions, joins of fixed depth | Deep recursive relationships |
| Document database | Nested JSON documents | Self-contained records | Many-to-many links |
| Time-series database | Timestamped measurements | High-rate ingestion, time windows | Arbitrary relationships |
| Vector database | Embedding vectors | Similarity search | Exact structural queries |
Graph and vector databases are increasingly combined: a knowledge graph supplies explicit facts and relationships, while vector search finds semantically similar items, and retrieval systems use both.
When a graph database is the right choice
Adopting a graph database adds a new system to operate, so the decision should rest on query patterns rather than on data that merely looks connected. Almost all data has relationships; the question is whether queries depend on traversing them at variable depth.
| Situation | Recommendation | Reason |
|---|---|---|
| Fraud rings sharing devices and addresses | Graph database | Patterns span several hops |
| Recommendations from shared behavior | Graph database | Neighborhood queries are natural |
| Order processing and invoicing | Relational database | Fixed joins, strong constraints |
| Occasional hierarchy queries | Relational with recursive CTE | No extra system needed |
| Network and dependency impact analysis | Graph database | Path finding across layers |
Limitations and pitfalls
Graph databases differ widely in their guarantees. Some offer full ACID transactions on a single primary with read replicas, while distributed engines trade some consistency for scale. Performance depends less on total node count than on the number of relationships touched per query, so a traversal that visits a few thousand edges stays fast even in a graph of billions.
The most frequent problems come from data shape and query design rather than from the engine itself. Modeling choices made early are hard to change once applications depend on specific labels and relationship types.
- Supernodes, nodes with millions of relationships such as a popular account, make traversals through them slow.
- Horizontal scaling is difficult, because partitioning a graph cuts relationships and turns local hops into network calls.
- Unbounded patterns such as
*without a depth limit can explore a large part of the graph and exhaust memory. - Modeling attributes as nodes, or relationships as properties, produces awkward and slow queries.
- Teams sometimes keep a duplicate copy in a relational system without a clear source of truth, causing drift.
Understanding it simply
A graph database stores information the way people draw a network on a whiteboard: circles for things and arrows for how they are connected. A person, a phone and a bank account are circles; “owns” and “sent money to” are arrows.
To answer a question, the database follows the arrows from one circle to the next, much like tracing a route on a subway map. It shines when the connections matter more than the individual records.
Applied in practice
A payment provider wants to detect accounts that are controlled by the same fraud ring even though each account looks normal on its own. It loads accounts, cards, devices, IP addresses and shipping addresses into a graph database as nodes, with relationships such as USED_DEVICE and SHIPPED_TO.
A nightly query searches for groups of accounts connected within three hops through shared devices or addresses and flags clusters above a size threshold. Analysts review each cluster as a picture of linked nodes rather than as separate rows. The approach finds rings that rule-based checks on single transactions missed, and investigators can see the whole network behind one suspicious payment in a few seconds.