---
title: "Graph database"
description: "A graph database stores data as nodes and relationships (edges) rather than rows and tables, optimized for traversing and querying densely connected data such as social networks, fraud graphs, or recommendation graphs."
canonical: "https://motherduck.com/glossary/graph-database/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "Puppygraph | MotherDuck Docs"
    url: "https://motherduck.com/docs/integrations/dev-tools/puppygraph/"
  - title: "DuckDB × cognee: Run SQL Analytics Right Beside Your Graph-Native RAG"
    url: "https://motherduck.com/blog/duckdb-cognee-sql-analytics-graph-rag/"
gated_asset:
  title: "DuckLake on MotherDuck"
  url: "https://motherduck.com/product/ducklake/"
---

# Graph database

> A graph database stores data as nodes and relationships (edges) rather than rows and tables, optimized for traversing and querying densely connected data such as social networks, fraud graphs, or recommendation graphs.

## Overview

A graph database models data explicitly as a network: nodes (entities, such as a person or a product) and edges (relationships between them, such as "purchased" or "follows"), often with properties attached to both. Popular graph databases include Neo4j, Amazon Neptune, and ArangoDB, typically queried with graph-specific languages like Cypher or Gremlin, or increasingly with the ISO-standard GQL. The core advantage over a relational database is traversal performance: relational databases model many-to-many relationships through joins, which get progressively more expensive as traversal depth increases (friend-of-a-friend-of-a-friend), whereas a graph database can follow pointer-like edges directly, keeping multi-hop traversal fast regardless of overall dataset size.

<glossary-callout guide="duckdb-book-brief" />

## When graph databases make sense

Graph databases tend to shine for problems that are fundamentally about relationship structure and path-finding: social network analysis, fraud ring detection, recommendation engines, knowledge graphs, and network/dependency analysis. If most of your queries are about traversing arbitrary-depth relationships rather than aggregating attributes across many records, a graph database's traversal-first storage model is usually a better fit than forcing that access pattern onto tables and joins.

## Relational and graph approaches together

Many practical relationship queries — a fixed number of joins, or hierarchical data expressed with a self-referencing foreign key — can be handled well in a standard SQL engine using recursive common table expressions (`WITH RECURSIVE`), which most SQL databases, including DuckDB, support for traversing fixed-depth or recursively-defined hierarchies like org charts or bill-of-materials structures. A dedicated graph database becomes more valuable specifically when traversal depth is unbounded or unpredictable and needs to stay fast as the graph grows, which is a workload relational engines (DuckDB included) are not purpose-built for.