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.
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.
Related terms
A directed acyclic graph (DAG) is a graph of nodes connected by one-way edges with no cycles, used to represent task dependencies so that execution order is unambiguous.
relational database →A relational database is a structured collection of data organized into tables with rows and columns.
Data orchestration →Data orchestration is the automated coordination, scheduling, and monitoring of interdependent data tasks—such as extracts, transformations, and loads—so they run in the correct order and recover cleanly from failure.
relational object →A relational object is a fundamental concept in relational databases, representing a structured collection of data organized into rows and columns.
result →The result keyword in SQL is not commonly used across all database systems, but in DuckDB, it has a specific meaning within the context of recursive queries.
Entity-relationship diagram (ERD) →An entity-relationship diagram (ERD) is a visual representation of a database's entities (tables), their attributes, and the relationships between them, used to design and document relational schemas.
FAQS
For shallow or fixed-depth relationships, yes — using joins or recursive CTEs. Dedicated graph databases pull ahead specifically for deep, unpredictable traversals where relational join costs grow quickly with depth.
Common ones include Cypher (popularized by Neo4j), Gremlin (Apache TinkerPop), and GQL, a newer ISO-standardized graph query language; these are distinct from SQL and are designed around pattern-matching over nodes and relationships.
