Graph databases

A graph database is a class of NoSQL database that stores data as a graph, a set of nodes connected by edges, with both carrying properties. Where a relational database keeps relationships implicit in shared column values and reconstructs them at query time through joins, a graph database stores each relationship as a first-class record, with an edge pointing directly from one node to its neighbor. The database can walk those edges without a join, which makes traversal of connected data cheap even when the relationships are deep and many.

The property graph model

Most graph databases follow the property graph model, built from three elements.

  • Nodes represent entities, eg. a Person, Movie, or Account.
  • Edges, sometimes called relationships, connect two nodes and carry a type, eg. ACTED_IN or TRANSFERRED_TO.
  • Properties are key-value pairs attached to a node or an edge, eg. a Person node with name and born, or an ACTED_IN edge with roles.

Edges are directed and can be traversed in either direction. Because the edge itself is a stored record, it can hold data that qualifies the relationship, such as a timestamp, a weight, or a role. This is the central contrast with a relational database, where a relationship is expressed through foreign keys or a join table and carries no data of its own.

Querying: traversal instead of joins

Graph databases are queried by traversing edges from a starting node, following a pattern of types and property filters, rather than by joining tables on shared keys. The cost of a traversal is proportional to the size of the subgraph visited, not to the size of the data set as a whole, so queries that hop several relationships deep stay fast as the graph grows. The same query against a relational store tends to require one join per hop, and join cost rises with table size.

Each product ships its own query language. Cypher, used by Neo4j, expresses graph patterns declaratively. Gremlin is a traversal language used by Amazon Neptune and others. SPARQL queries RDF triple stores.

RDF triple stores

A second family of graph databases stores data as RDF triples, subject-predicate-object statements, rather than as property graphs. RDF triple stores are queried with SPARQL and underpin ontology modeling and knowledge graph work built on the RDF, RDF Schema, and OWL standards. The property graph and RDF camps overlap in intent but differ in model and tooling, and some products, such as Amazon Neptune, support both.

Use cases

Graph databases suit workloads where the relationships matter as much as the entities.

  • Recommendation engines traverse purchase, view, and similarity edges to suggest related items.
  • Fraud detection follows chains of accounts, addresses, and transactions to expose rings that a single-table query would miss.
  • Knowledge graphs of entities and their relations, often built on RDF triple stores.
  • Social networks and identity and access management, where group membership and permissions are naturally graph-shaped.

They are a poor fit for bulk tabular analytics or for workloads dominated by single-record reads, where a relational database or a document store is simpler and faster.

Trade-offs

Graph databases make relationship traversal cheap, but they pay for it elsewhere. Sharding a graph across nodes is hard, because edges routinely cross shard boundaries, so most graph databases favor vertical scaling over the horizontal scaling that other NoSQL families take for granted. ACID guarantees are common on a single node but harder to preserve across a distributed graph. Tooling and operator experience are thinner than for relational stores, and the query languages are product-specific, which complicates portability.

Examples

  • Neo4j. The most widely deployed property graph database, queried with Cypher, with full ACID transactions on a single instance.
  • Amazon Neptune. A managed service supporting both property graphs (Gremlin) and RDF triple stores (SPARQL).
  • TigerGraph. A distributed graph database tuned for deep-link analytics at scale.
  • ArangoDB. A multi-model store combining graph, document, and key-value access.
  • GraphDB (Ontotext). An RDF triple store with reasoning support for knowledge graph workloads.

See also