Native Graph Traversal

GraphTraversalPerformance

Stable On by default · production-ready

What it is

Native graph traversal is what makes graph-relational duality fast. When you declare an edge table, AetheriusDB treats each relationship as a first-class, traversable connection: following it resolves directly to the related row, with no separate index structure to probe or maintain. You query it with the standard SQL/PGQ MATCH syntax; the planner picks the native traversal automatically when it is available.

Why it matters

Conventional graph engines advertise “index-free adjacency,” but in practice each hop still chases a scattered reference, which is slow. In AetheriusDB, traversals stay fast as the graph grows — multi-hop walks do not degrade into a series of random lookups.

• Fast single-hop traversal — following an edge resolves directly to the neighbouring row instead of probing an index.
• High-throughput multi-hop walks — breadth-first traversals over many edges stay fast, and edge labels and filters are applied as the walk runs.
• Zero overhead for non-graph tables — if you never declare an edge table, the feature costs nothing.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80

  Q[MATCH pattern<br/>a -e- b]:::a --> P[Planner picks<br/>native traversal]:::b
  P --> X[Engine walks<br/>the relationships]:::b
  X --> R[Result rows]:::g

How you use it

There is no special syntax for the traversal itself. Declare a property graph over your tables, then write MATCH patterns — the planner uses the native traversal when it can.

-- Node table + an edge table (an edge is a table with two foreign keys).
CREATE TABLE people (id BIGINT PRIMARY KEY, name TEXT);
CREATE TABLE friend (person_a BIGINT, person_b BIGINT, since DATE);

-- Declare a property graph; relationships become traversable in MATCH.
CREATE PROPERTY GRAPH social
  VERTEX TABLES (people KEY (id))
  EDGE TABLES (
    friend
      SOURCE      KEY (person_a) REFERENCES people
      DESTINATION KEY (person_b) REFERENCES people
  );

-- Traverse the FRIEND edges from a starting node.
SELECT b AS friend_id
FROM social MATCH (a:people)-[:friend]->(b:people)
WHERE a.id = 42;

The same pattern extends to longer paths, and a vector pre-filter can narrow the starting set before the walk runs, all in one query.

Key concepts

Concept	Meaning
Native hop	Following a relationship resolves directly to the related row, not via an index probe.
Edge label	A name on a relationship you can filter on inside a MATCH pattern.
Multi-hop path	A MATCH expression that chains several hops in one traversal.
Whole-graph analytics	Graph algorithms over dense subgraphs run efficiently with no tuning required.

Notes & caveats

Tip

Whole-graph algorithms (PageRank, Louvain, Connected Components) over very dense subgraphs are executed efficiently with no tuning required — the engine adapts to the workload automatically.

Heads up

Cross-cluster traversals — relationships whose destination lives on a different node — currently resolve through the local node. Fully distributed shard-to-shard graph walks are evolving alongside the cluster coordination layer.

Graph-Relational Duality →

The declarative surface that makes relationships traversable.

Graph Index →

Declare a relationship to serve selective joins as a direct lookup, no scan.

Spectral Foreign Keys →

Non-blocking referential integrity for graph edges.

Distributed AetheriusDB →

How traversals behave across a cluster.