Neo4j — The Graph Model & Cypher Basics

Four building blocks make up every Neo4j graph:

• Nodes — the "things": a person, a product, an account. A node can carry one or more labels (:Person, :Employee) that categorize it, similar in spirit to a table name, except a single node can hold multiple labels at once.
• Properties — key-value pairs on either a node or a relationship (name: 'Alice', since: 2019).
• Relationships — the connections: always typed (exactly one type, like :FOLLOWS or :WORKS_AT) and always directed (they point from one node to another) — but they're queryable in either direction regardless of which way they were created.
• Relationship properties — a relationship isn't just a link; it can carry its own data. A :FOLLOWS relationship might have a since property; a :WORKS_AT relationship might have a role and startDate.

CREATE (alice:Person {name: 'Alice', age: 29})
CREATE (bob:Person {name: 'Bob', age: 31})
CREATE (acme:Company {name: 'Acme Corp'})
CREATE (alice)-[:FOLLOWS {since: 2021}]->(bob)
CREATE (alice)-[:WORKS_AT {role: 'Engineer', startDate: date('2022-03-01')}]->(acme);

Notice the relationship carries data (since, role, startDate) exactly the way a node's properties do — a genuine modeling capability a plain foreign key column can't express without an extra join table of its own.

Cypher's pattern syntax is meant to look like the graph it describes: parentheses () are nodes, square brackets [] are relationships, and -> / <- show direction. Once you can read a pattern as a little ASCII drawing, most of Cypher follows naturally.

// CREATE — always creates new nodes/relationships, never checks if they already exist
CREATE (p:Person {name: 'Priya', city: 'Bengaluru'});

// MATCH ... WHERE ... RETURN — the core read pattern, directly analogous to SQL's FROM ... WHERE ... SELECT
MATCH (p:Person)
WHERE p.city = 'Bengaluru'
RETURN p.name, p.age;

// Traversal is just a longer pattern in the same MATCH
MATCH (p:Person {name: 'Priya'})-[:FOLLOWS]->(followed:Person)
RETURN followed.name;

// Filtering on a relationship's own property
MATCH (p:Person)-[f:FOLLOWS]->(other:Person)
WHERE f.since < 2022
RETURN p.name, other.name, f.since;

A few habits carry over directly from SQL: WHERE filters, and you can filter on node properties, relationship properties, or both in the same clause. What doesn't carry over: there's no JOIN keyword, because a relationship in the pattern is the join — (p)-[:FOLLOWS]->(other) already tells Neo4j exactly which two node sets to connect and how, with no separate ON condition to write.

RETURN supports the aggregate functions you'd expect — count(), collect(), avg() — and clauses like ORDER BY and LIMIT work exactly as they read:

MATCH (p:Person)-[:FOLLOWS]->(other:Person)
RETURN p.name, count(other) AS followingCount
ORDER BY followingCount DESC
LIMIT 5;

MERGE is Cypher's create-if-not-exists: it first tries to MATCH the given pattern, and only falls through to CREATE if nothing matched.

// Safe to run any number of times — only ever one Person node with this email
MERGE (p:Person {email: 'alice@example.com'})
RETURN p;

MERGE matches on the entire pattern you give it, properties included — MERGE (p:Person {email: $email}) will happily create a second node if you later MERGE (p:Person {email: $email, city: 'Pune'}), because as a pattern it's not identical to the first one. Keep the property or properties you're merging on minimal and stable (usually whatever your actual uniqueness key is), and set everything else afterward with ON CREATE SET / ON MATCH SET:

MERGE (p:Person {email: $email})
ON CREATE SET p.name = $name, p.createdAt = timestamp()
ON MATCH SET p.lastSeenAt = timestamp();

This runs the createdAt assignment only the first time this person is ever merged, and lastSeenAt on every subsequent run — exactly the shape of logic an idempotent import or upsert endpoint needs. MERGE also works on whole patterns, not just single nodes — MERGE (a)-[:FOLLOWS]->(b) creates the relationship only if that exact a-to-b :FOLLOWS edge doesn't already exist, which is precisely how you avoid accidentally doubling up relationships too. A uniqueness constraint (Chapter 03) is the belt-and-suspenders way to make duplicate nodes impossible even if a stray CREATE slips through.

NoSQL Foundations, Chapter 1 places graph databases as the fourth NoSQL family, alongside key-value, document, and column-family stores — each earning its place by being the best fit for one specific access pattern (see that chapter's family table). Graph's access pattern is traversing relationships multiple hops deep.