Index-Free Adjacency, Variable-Length Paths & Constraints

Why Multi-Hop Queries Are Fast

Index-free adjacency: each node directly stores physical pointers to its relationships, so traversing to a neighbor is a fast, constant-time pointer-follow per hop — unlike relational JOINs, which get more expensive as hop count grows. This is the core technical reason graph databases suit deeply-connected, multi-hop traversal (social networks, recommendations, fraud detection).

Variable-Length Relationships

// find connections 1 to 3 hops away — concise, no recursive SQL needed
MATCH (a:Person {name: "Ada"})-[:KNOWS*1..3]->(b:Person)
RETURN DISTINCT b

Relationship Types vs. Node Labels

A relationship type (:PURCHASED) categorizes a relationship, parallel to how a label categorizes a node — but a relationship has exactly ONE type, while a node can carry multiple labels simultaneously. A relationship-with-properties (like PURCHASED.quantity) avoids the intermediate join-table pattern a relational many-to-many-with-attributes design would require.

Indexes & Constraints

CREATE INDEX FOR (p:Person) ON (p.email)
CREATE CONSTRAINT FOR (p:Person) REQUIRE p.email IS UNIQUE

An index speeds up lookups by that property instead of scanning every labeled node. A uniqueness constraint enforces no two Person nodes share an email — similar in spirit to a relational unique column constraint.

Query Performance & Fit

Give MATCH patterns a label and/or indexed filter as early as possible — an unlabeled, unfiltered starting node forces the planner to consider far more candidates, similar to a SQL query that can't use an index. Choose Neo4j when actual query patterns are relationship-traversal-heavy; simple flat/tabular data with shallow relationships may still be better served by a relational database's tooling and familiarity.