Modeling Entities & Relationships

Node vs. Edge vs. Property

Before you write a single query, you make three decisions over and over: should this thing be a node, an edge, or a property? Get these right and traversals stay simple; get them wrong and you'll fight your own schema for the life of the project.

The Decision Rules

• Make it a node if it has its own identity, can be connected to many other things, or you'll ever want to query it on its own. People, companies, products, orders, addresses.
• Make it an edge if it describes how two nodes relate. WORKS_AT, PURCHASED, LOCATED_IN.
• Make it a property if it's a simple attribute of a single node or edge and you won't traverse to it. name, born, price, an edge's since date.

The Litmus Test

Ask: "Will I ever want to traverse to this, or count how many things share it?"

• "How many people live in Berlin?" → you traverse to Berlin → Berlin is a node, not a city: "Berlin" property.
• "What is Alice's middle name?" → you never traverse to a middle name → it's a property.

This is the single most common beginner mistake: burying queryable entities inside properties. A city string can't be connected to a country, can't have a population, and forces fragile string matching.

Edges Carry Data Too

In a property graph, edges are first-class — they can hold properties. Employment isn't just (Alice)-[:WORKS_AT]->(ACME); it's WORKS_AT { since: 2021, title: "Engineer" }. Put facts about the relationship on the edge, not on either node.