Graph Data Modeling and Cypher: Make Relationships First-Class

A graph database is useful when relationships are part of the question, not merely a way to decorate entities with arrows.

Property graph building blocks

Neo4j’s property graph model uses:

• nodes for entities;
• labels for node roles;
• directed, typed relationships;
• properties on nodes and relationships.

(:Researcher)-[:AUTHORED {position: 1}]->(:Paper)
(:Paper)-[:CITES]->(:Paper)
(:Paper)-[:ABOUT]->(:Topic)

Author position belongs on AUTHORED because it describes the connection, not either endpoint.

In plain terms: a relational junction row and a graph relationship often represent the same fact. The graph model makes following chains of those facts the central operation.

Start a traversal selectively

Create an identity constraint so the planner can locate the starting node:

CREATE CONSTRAINT researcher_id IF NOT EXISTS
FOR (r:Researcher)
REQUIRE r.id IS UNIQUE;

Then traverse from a selective anchor:

MATCH (r:Researcher {id: $researcherId})-[:AUTHORED]->(p:Paper)
      -[:ABOUT]->(t:Topic)
RETURN t.name, count(*) AS papers
ORDER BY papers DESC;

An index helps find r. It does not make an unlimited traversal cheap. Cost then depends on relationship degree, path length, and filtering.

Variable-length paths need boundaries

MATCH path = (a:Researcher {id: $id})-[:COAUTHORED_WITH*1..3]-(other)
WHERE other <> a
RETURN DISTINCT other.id, length(path)
LIMIT 100;

The 1..3, relationship type, selective start, and result limit all constrain work. An unbounded pattern over a dense graph can expand combinatorially.

In plain terms: “friends of friends” sounds small until each person has hundreds of neighbors. Path length is a performance parameter, not only a business requirement.

Read the plan

Prefix a read query with PROFILE to execute it and collect runtime statistics, or EXPLAIN to inspect the plan without running it.

Look for:

• NodeIndexSeek rather than scanning every node label at the start;
• unexpectedly large row multiplication after Expand operators;
• filters applied only after a large traversal;
• repeated expansions caused by an overly broad pattern.

Do not force an index hint first. Fix identity constraints, query predicates, and statistics before overriding the planner.

When a graph is the wrong model

Use a relational model when the workload is dominated by tabular reporting, stable joins, aggregates, and strong multi-row constraints. Use a document model when data is normally read as bounded aggregates. A graph is strongest when variable relationship paths and neighborhood questions dominate.

Review card

• Model relationship attributes on relationships.
• Use constraints and indexes to find selective starting nodes.
• Traversal cost depends on degree and path length.
• Bound variable-length paths deliberately.
• EXPLAIN plans; PROFILE executes and measures.
• Choose graph storage for graph-shaped questions, not graph-shaped diagrams.

Sources

• Neo4j constraints
• Neo4j indexes

(:Researcher)-[:AUTHORED {position: 1}]->(:Paper)
(:Paper)-[:CITES]->(:Paper)
(:Paper)-[:ABOUT]->(:Topic)

CREATE CONSTRAINT researcher_id IF NOT EXISTS
FOR (r:Researcher)
REQUIRE r.id IS UNIQUE;

MATCH (r:Researcher {id: $researcherId})-[:AUTHORED]->(p:Paper)
      -[:ABOUT]->(t:Topic)
RETURN t.name, count(*) AS papers
ORDER BY papers DESC;

MATCH path = (a:Researcher {id: $id})-[:COAUTHORED_WITH*1..3]-(other)
WHERE other <> a
RETURN DISTINCT other.id, length(path)
LIMIT 100;