Compare Graph Architectures

Explore five approaches to storing graph data and executing graph queries. Understand their strengths and tradeoffs, and where PuppyGraph’s table-native approach fits.

  1. Pointer / Linked Adjacency Storage: Neo4jOrientDBCan be difficult to scale
  2. Key-Value Store + Adjacency List: JanusGraphNebulaGraphDgraphCan cause many random KV lookups
  3. In-Memory Graph: MemgraphFalkorDBNetworkXLarge memory footprint
  4. Graph Query → SQL: Apache AGEOracle DatabaseSpanner GraphCan generate expensive joins
  5. Columnar / Table-Native Graph Engine: PuppyGraphNo separate graph copy

Five architectures at a glance.

The underlying storage and execution design shapes each approach’s strengths and tradeoffs.

Graph storage and query architectures: core ideas, advantages, limitations, and representative examples
ArchitectureCore IdeaAdvantagesLimitationsRepresentative Examples
01

Pointer / Linked Adjacency Storage

Store nodes and edges in a disk-backed graph store with direct record references. Traverse relationships by following those references to connected records.

Fast neighbor navigation.

Efficient edge insertion and deletion.

Pointer chasing can have poor cache locality.

Distributing the structure and scaling to very large datasets can be difficult.

  • Neo4j(native record store)
  • OrientDB(disk-based record links)
02

Key-Value Store + Adjacency List

Organize neighboring nodes and edges as adjacency data in a disk-backed key-value store. Traverse relationships by looking up keys associated with the current node.

Simple, scalable storage.

Fast direct neighbor lookup.

Multi-hop traversals can cause many random KV lookups.

Reads across partitions can be expensive.

  • JanusGraph(Cassandra / HBase backend)
  • NebulaGraph(RocksDB key-value storage)
  • Dgraph(Badger key-value store)
03

In-Memory Graph

Load the entire graph representation into RAM and execute traversals or graph algorithms in memory.

Fast traversal and graph computation.

Good memory locality when the data structures are designed well.

Large memory footprint, plus loading and refresh costs.

Very large graphs can be difficult to accommodate.

  • Memgraph(in-memory storage mode)
  • FalkorDB(Redis module)
  • NetworkX(Python library)
04

Graph Query → SQL

Compile graph queries or patterns into relational query plans, then execute them with a relational database.

Reuses mature SQL storage, optimization, transactions, and tooling.

Complex multi-hop and variable-length traversals can generate expensive joins or recursive SQL.

  • Apache AGE(PostgreSQL extension)
  • Oracle Database(SQL property graphs)
  • Spanner Graph(Google Cloud Spanner)
05

Columnar / Table-Native Graph Engine

Keep source data in tables and columnar formats. Execute specialized graph operators directly over that data, without first loading a traditional graph store.

No separate graph copy is required.

Columnar and vectorized execution.

Uses existing lakehouse and warehouse data.

Requires a specialized graph execution engine and sophisticated optimization for multi-hop queries.

  • PuppyGraph
See how PuppyGraph works →

Apache AGE and the Apache AGE logo are trademarks of The Apache Software Foundation.

Try PuppyGraph

High-performance graph queries on your existing data.

PuppyGraph’s distributed engine scales graph queries across your databases, warehouses, and lakehouses. No data movement required.

$ docker run -p 8081:8081 \
  -p 8182:8182 -p 7687:7687 \
  puppygraph/puppygraph:latestPulling puppygraph/puppygraph:latestStarting PuppyGraphWeb console listening on 0.0.0.0:8081Gremlin endpoint listening on 0.0.0.0:8182PuppyGraph is running# no pipelines · no second database · no data movement