Neo4j Cypher Cheat Sheet

Neo4j Cypher Cheat Sheet

Cypher is Neo4j's query language and it's not hard to learn, but the syntax has enough quirks that you'll forget the details on any given Tuesday. This guide is meant to be something you can actually use when you're stuck halfway through writing a traversal. The official one lives at neo4j.com/docs/cypher-cheat-sheet/. It's updated with each release, so bookmark that rather than downloading a PDF that'll rot in six months. There's also a community-maintained print-friendly version scattered across GitHub repos, but the official sheet is what I actually reference. If you want a local copy, the Browser's built-in :help command in Neo4j 5+ surfaces the same content inline. Saves a tab.

Reading and Writing Patterns

The core unit of Cypher is the pattern. You describe what you're looking for using ASCII art–style notation. Match a relationship:

(alice)-[:FRIENDS_WITH]->(bob)

Match without caring about direction: Unbounded relationship (any length, any type): I spent three days debugging a query once because I wrote -[:*]- instead of -[:*0..]- on a graph with 40 million edges. The former runs a full depth-first blowup that never returns. The latter returns in under two seconds. Always bound your variable-length traversals unless you actually want the database to self-immolate.

Use CALL { ... } for multiple creates in a transaction block when you're batching. Individual CREATE statements outside a union run as separate transactions by default, which is a footgun if you expect atomicity. Filter with WHERE: String operations:

Index usage matters more than people admit. A WHERE p.name = 'X' on an unindexed label-property pair will trigger a full label scan. That's how queries that run in milliseconds overnight become "why is the DB down" incidents. Bloom filters exist for equality predicates on large cardinality columns. Use them if you're hitting index cardinality limits, otherwise just stick to regular B-trees. Common aggregation functions: count(), sum(), avg(), min(), max(), collect(), percentileCont().

count(*) counts rows. count(p.id) counts non-null values. The difference matters when you're using LEFT joins via OPTIONAL MATCH.

Collecting Results Into Lists

MATCH (p:Person)-[:FRIENDS_WITH]->(friends)
RETURN p.name, collect(friends.name) AS friend_names

This is the go-to for flattening relationship data into a single row per node. Watch out for cartesian products if you combine collect() with additional MATCH clauses on the same variable without proper scoping. DELETE removes nodes and relationships. DETACH DELETE also removes any orphaned relationships. REMOVE only strips properties or labels, it doesn't touch relationships. The dangerous part: you cannot DELETE a node that still has relationships attached unless you use DETACH DELETE. Forgetting that throws a constraint error that stops the entire transaction.

Conditional Updates

MATCH (p:Person)
WHERE p.status = 'inactive'
SET p.last_active = timestamp()
WHERE p.last_active 
(timestamp() - 2592000000)
REMOVE p.profile_complete

Chain WHERE after SET for post-update filtering. Useful when you need to clean up stale data in the same pass. SKIP/LIMIT works but has a hidden cost: Neo4j still evaluates the entire preceding plan before discarding the first N rows. For deep pagination on graphs with millions of nodes, this gets expensive fast. My workaround for large dataset exports: use a keyset cursor based on an indexed property rather than SKIP. Fetch the last seen value, then query with WHERE id > {last_id} LIMIT 100. Cuts my export times from 40 minutes to about 3 minutes on a 2M-node dataset.
Named Paths

MATCH path = (a:Person)-[:FRIENDS_WITH*1..3]->(b:Person)
WHERE a.name = 'Alice'
RETURN nodes(path) AS people, relationships(path) AS connections

Storing the full path gives you both the node list and relationship list in one go. This is how you build graph visualizations without re-traversing the data. The APOC library is essentially mandatory for production work. Some useful procedures: apoc.periodic.iterate processes large result sets in batches instead of materializing everything in memory. Without it, a query over 100k+ rows will OOM the server. I learned this the hard way after a Friday deploy.


allShortestPaths returns every shortest path between two nodes. Use this when you need connectivity analysis, not just a single route. The algo procedures require the APOC core plugin and run in the algorithm engine, not the query planner. They're faster for pathfinding at scale but lose some of the declarative safety of standard Cypher. OPTIONAL MATCH is the Cypher equivalent of a LEFT JOIN. Use it when you want results even if the relationship doesn't exist. The catch: any aggregation after an OPTIONAL MATCH will treat nulls differently than you might expect from SQL. collect() will include nulls if you're not careful.
Cypher isn't SQL. The optimizer behaves differently, and some SQL habits actively hurt you here. A typical unoptimized query against a medium graph (100k nodes, 500k relationships) that should take seconds can drag to 30+ minutes if there's a label scan or cartesian product hidden in the plan. I check PROFILE on every new query before running it against production data. The USING hint forces the optimizer to use a specific index. Use it when the planner picks a full scan, but don't overuse it — hints bypass the planner's cost model and can make queries worse if you're wrong about the selectivity.
The official cheat sheet covers the basics well: MATCH, CREATE, SET, DELETE, REMOVE, WITH, ORDER BY, SKIP/LIMIT, and aggregation functions. What it doesn't cover well is the operational stuff — batching, index selection, APOC usage, and performance debugging. The gaps are where you'll spend most of your time. Bookmark the official sheet for syntax reference, but invest in learning PROFILE output and APOC's periodic procedures. Those two skills will save you more time than memorizing every clause combination. Neo4j 5.x introduced some syntax changes from 4.x, mainly around naming conventions and improved query planning. If you're migrating an existing codebase, test queries against the actual version, not just the documentation for the latest release.