Graph Database

A graph database stores data as nodes (entities) and edges (relationships), both of which can carry properties. It is designed to traverse connections quickly.

Why it matters

Questions like "friends of friends", shortest path, or fraud rings need many self-joins in a relational database, which gets slow as depth grows. Graph databases follow stored relationships directly, so traversal cost depends on the portion of the graph visited rather than total table size. Many systems also offer indexes on node and edge properties for fast starting points. Common uses are social networks, recommendation engines, and knowledge graphs.

Example

MATCH (a:Person {name: "Asha"})-[:FRIEND]->()-[:FRIEND]->(fof)
WHERE fof <> a
RETURN DISTINCT fof.name

This Cypher-style query returns friends of Asha's friends.

Common mistakes

• Using a graph database for simple tabular data where a relational one is cheaper and simpler.
• Ignoring supernodes, nodes with millions of edges that make traversals slow.
• Assuming all graph databases share one query language. Cypher, Gremlin, and SPARQL differ.

Related

• NoSQL
• SQL JOIN
• Relational database

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.