Overview

A property graph is built from nodes, relationships, labels, and properties as first-class citizens. The smallest fact is a single labeled node carrying a bag of key-value properties (Example 1) -- an identity via the label, and a set of typed facts about it, with no fixed column schema constraining what properties any other node with the same label must carry.

In a labeled-property graph, a fact is usually bundled into a node object -- a node's label plus its properties, in one addressable unit (Example 1). In RDF, every fact -- including what a property graph would call a "property" -- is its own standalone subject-predicate-object triple (Example 25); there is no single node object bundling a resource's facts together, only however many triples happen to share that resource as their subject.

Deeply connected, relationship-heavy, variable-depth questions -- "friends of friends of friends," a bill-of-materials explosion, a knowledge-graph chain across several entity types -- are where a graph traversal wins, because the query's shape barely changes as the hop count grows (Example 19, Example 38, Example 65). A graph database is not a universal replacement for a relational store; the win is specific to traversal-heavy questions, not every kind of query.

Each node stores a direct pointer to its own relationships, so expanding one hop from a node costs roughly the same regardless of the graph's total size (Example 18) -- the cost tracks the node's own neighborhood, not the whole database. It does NOT guarantee that neighborhood stays small: a node with an unusually high degree (a supernode) still has to enumerate all of its own relationships, so the flat-cost guarantee is scoped to "proportional to the starting node's own degree," not "constant time no matter what" (Example 44).

MATCH/WHERE/RETURN -- MATCH finds every subgraph matching a drawn pattern, WHERE filters those matches down to the rows satisfying a boolean condition, and RETURN projects what actually comes back (Example 4, Example 5, Example 6). Every later, more complex read query -- OPTIONAL MATCH, WITH-pipelines, CALL {} subqueries -- extends this same three-clause shape rather than replacing it.

CREATE unconditionally writes the pattern every time it runs -- rerunning it twice leaves two nodes (Example 1). MERGE matches the pattern if it already exists, and only creates it if it does not -- rerunning the same MERGE twice still leaves exactly one node (Example 10). ON CREATE SET/ ON MATCH SET let one MERGE statement branch on which path it actually took, e.g. setting a first-seen timestamp only on creation and incrementing a counter only on a repeat match (Example 11).

A Cypher relationship pattern (()-[:REL]->()) is directed and typed, and both narrow what a MATCH finds (Example 3, Example 6, Example 7). Reversing the arrow or naming the wrong type against real data simply matches zero rows instead of raising an error -- there is nothing structurally wrong about the query, it is just describing a shape that does not exist in the graph, which is why Example 9's deliberately direction-agnostic ()--() pattern exists for when direction genuinely does not matter.

A Cypher query describes a graph shape, and the engine -- not the query author -- enumerates every place in the graph that shape actually occurs (Example 6). A multi-hop relational equivalent instead requires the author to hand-write one additional self-join per hop (Example 19); Cypher's pattern stays a single MATCH regardless of hop count, with only the bound inside * changing.

The classic [:REL*1..3] syntax (still valid, not GQL-conformant) and the modern quantified-relationship syntax -[:REL]->{1,3} (GQL-conformant, Cypher 25) both traverse a variable number of hops in one pattern (Example 14, Example 15). Bounding the traversal (*1..3 rather than unbounded *) keeps the query's cost predictable -- an unbounded * risks scanning the entire connected component, which is why shortestPath()'s internal use of unbounded * is safe specifically because the function stops at the first shortest match, while the same unbounded * in a plain MATCH is a performance hazard.

shortestPath()/allShortestPaths() (Example 16, Example 17) and the modern SHORTEST/ ALL SHORTEST/ANY path selectors (Example 79) count hops -- "fewest hops between these two nodes." gds.shortestPath.dijkstra/gds.allShortestPaths.dijkstra (Example 60, Example 61) minimize total edge weight instead -- "cheapest total cost," which can favor a longer-hop-count route if its summed weight is lower (Example 60's A-C-Z route beating the equal-hop-count but heavier A-B-Z route).

Deciding whether a fact becomes a node, a property, or a relationship -- because that decision determines what a later query can traverse to directly (Example 12, Example 13). A fact stays a property when it is only ever read, never traversed into, and has no attributes of its own (Example 12); it graduates to its own node the moment it needs attributes of its own or needs to be a target other entities also point at (Example 54). A fact about the connection itself, not either endpoint, belongs on the relationship (Example 13).

A relationship replaces a join table outright -- the many-to-many fact IS the edge, with no separate junction table to design, index, or join through (Example 33). Unlike a plain foreign-key join table, a relationship can carry its own properties directly (a grade, a rating, a timestamp), attached exactly to the one pairing it describes, with no extra column needed on a junction row (Example 34).

A directed [:REPORTS_TO] relationship walked forward with an unbounded * answers "who do I ultimately report to" (Example 35); the identical relationship type walked with the arrow reversed answers "who reports to me, directly or indirectly" (Example 36). No second relationship type or schema change is needed -- only the direction the pattern is walked changes.

A BOM is recursive by nature -- assemblies containing sub-assemblies containing parts, to arbitrary depth (Example 37). A recursive SQL CTE must be written explicitly as a base case plus a recursive UNION ALL step that the author keeps in sync with the schema (Example 38); [:PART_OF*] expresses the identical recursive structure as one pattern, shifting that bookkeeping into the query engine itself.

It is fundamentally a co-occurrence pattern: through what a user bought, out to who else bought it, out to what else they bought, excluding anything the user already owns (Example 39). A hand-rolled minimum-overlap threshold (Example 40) treats every co-buyer above the cutoff the same; gds.nodeSimilarity (Example 59) instead produces a continuous Jaccard-style similarity score, letting Example 62 pick specifically the MOST similar co-buyer rather than any co-buyer clearing a fixed bar.

A shared-attribute ring -- two accounts that should be independent sharing a device or identifier -- surfaces as a two-hop pattern match with an inequality filter excluding self-matches (Example 41). A circular-payment cycle -- money flowing back to its own origin -- surfaces by binding both ends of a variable-length pattern to the same starting variable (Example 42). Example 63 combines both ideas with Louvain community detection, flagging an unusually dense, self-contained cluster as a possible ring.

A supernode is a node whose relationship count (degree) massively exceeds its neighbors' (Example 43). Index-free adjacency guarantees a hop's cost tracks the STARTING node's own degree, not the graph's total size (co-04) -- but that guarantee says nothing about how large that one node's own degree happens to be, so expanding through a 50,000-relationship supernode genuinely enumerates 50,000 relationships, measurably slower than an ordinary node (Example 44). Example 72's mitigation is refactoring the supernode's edges through an intermediate grouping node.

Sharding independent rows (say, by customer ID) never needs a cross-shard join, because rows genuinely do not reference each other. A densely connected graph has no such guarantee -- any partition boundary drawn is likely to cut real relationships (Example 45), and every cut relationship becomes a network round trip at query time instead of a local, in-memory pointer follow. Example 73 shows a community-aware split minimizing that cut versus a naive ID-range split that has no such guarantee.

Neo4j operations run inside fully ACID transactions -- an exception raised partway through a multi-write transaction rolls back EVERY write already attempted in that same transaction, not just the failing one (Example 22). This is a genuinely different guarantee from eventual consistency common elsewhere in NoSQL: Neo4j also detects concurrent conflicting writes to the same node via locking, forcing one transaction to fail or retry rather than silently letting the second write corrupt the first (Example 74).

LOAD CSV (Example 23) runs online, row-at-a-time, inside the normal transactional write path, typically paired with MERGE for idempotent reruns -- the right tool for routine, ongoing loads of a few thousand rows. neo4j-admin database import full (Example 24) loads an entire fresh database offline, against a stopped and empty target, by writing storage files directly at far higher throughput -- the right tool for an initial bulk load of millions of rows, at the cost of needing dedicated :ID/:START_ID/:END_ID/:TYPE CSV headers and only running against an empty database.

Neo4j ships two parallel Cypher dialects: Cypher 5, frozen and bug-fixes-only, and Cypher 25, evolving (Example 52, Example 53) -- see the course overview's dated Accuracy notes for the calendar version at which Cypher 25 became the default, since that specific detail moves release to release. Prefixing a query with CYPHER 5 or CYPHER 25 pins that one statement to the named dialect regardless of the database's own configured default -- Example 15's quantified-relationship syntax and Example 79's SHORTEST selector are Cypher-25-only features that would not be available under a query pinned to Cypher 5.

A uniqueness constraint (CREATE CONSTRAINT ... IS UNIQUE) is enforced eagerly at write time, rejecting a duplicate value before it is ever written (Example 20); an index (CREATE INDEX) accelerates property lookups without enforcing anything, confirmed by EXPLAIN showing NodeIndexSeek instead of a full label scan (Example 21). Property graphs are schema-optional by default -- without an explicit constraint, nothing stops two nodes from carrying an identical "unique" value (Example 1), which is why Example 75 shows a bulk import tool's own id-uniqueness check catching a different problem than a real property-level constraint would.

Any three of: WITH, which passes computed values forward into the next query stage, letting a query filter on an aggregate result the way WHERE alone cannot (Example 28); UNWIND, which expands a list into one row per element (Example 29); count()/collect(), which reduce a group of rows to a number or a list respectively, grouping implicitly by whatever is not aggregated (Example 30); ORDER BY/LIMIT/SKIP, the standard paging triple (Example 31); or CALL (var) { ... }, a correlated subquery scoped explicitly to the outer variables passed in (Example 32).

WHERE matches a triple pattern -- subject, predicate, and a variable in the object position -- binding that variable to every object that completes the pattern for every matching triple (Example 26). Structurally this is the same idea as Cypher's MATCH binding a variable to every node completing a graph pattern (Example 6) -- both are declarative pattern-matching, just over triples versus labeled nodes and relationships. OPTIONAL/FILTER (Example 50) mirror Cypher's OPTIONAL MATCH/WHERE, and CONSTRUCT (Example 76) builds a new graph of triples from a matched pattern rather than returning tabular bindings.

Gremlin (Apache TinkerPop) is imperative and step-chained -- addV(), addE().from().to(), has(), out(), repeat().times()/repeat().until() -- rather than Cypher's single declarative pattern (Example 46, Example 47, Example 48). has() filters a vertex set the same way an inline {property: value} filter narrows a Cypher MATCH; out('type') steps one hop forward along a named edge label, the Gremlin equivalent of a directed, typed Cypher relationship pattern. Gremlin is portable across many graph engines beyond Neo4j (JanusGraph, Amazon Neptune, and others).

Running centrality, community-detection, or similarity algorithms directly against the live transactional graph on every call would be prohibitively slow at scale -- gds.graph.project builds a stable, named in-memory snapshot once, up front, that every later gds.* call in the same session refers back to by name (Example 55). Three algorithm families: centrality (PageRank, Example 56; betweenness, Example 57), community detection (Louvain, Example 58), and weighted shortest path (Dijkstra, source-target and single-source, Example 60/Example 61) -- alongside node similarity (Example 59).

An unbounded variable-length pattern, [:REPORTS_TO*], walked upward. It traverses as far as the chain actually goes without needing to know the depth in advance (co-09, co-13; Example 35).

MERGE, not CREATE. MERGE matches an already-loaded node instead of creating a second one, so a retried run is a genuine no-op (co-06; Example 10, Example 66).

OPTIONAL MATCH in place of a second plain MATCH. A plain MATCH behaves like an inner join and drops any row where the second pattern finds nothing; OPTIONAL MATCH preserves it with NULL instead (co-05; Example 27).

A two-hop shared-attribute pattern, (a)-[:USES]->(d)<-[:USES]-(b), with a WHERE a <> b filter excluding a device matching against itself (co-16, co-08; Example 41).

A bound parameter ($name), never f-string/.format interpolation into the query text -- the same discipline followed throughout this course's Python driver examples (Example 18's n=n, Example 44's name=name, and every capstone-preview script). The driver binds the value as an opaque parameter, so nothing it contains can change the query's shape.

A single MATCH (t:Team)<-[:PLAYS_FOR]-(p:Player) with collect(p.name), or a CALL (t) { ... } subquery scoped per team -- either replaces the per-team loop with one round trip that returns every team's player list already grouped (co-23; Example 30, Example 32).

Either a WITH ... count(DISTINCT shared) AS overlap WHERE overlap >= N threshold (co-15, co-23; Example 40), or the more principled fix, gds.nodeSimilarity's continuous Jaccard-style score, which lets a query rank co-buyers by strength instead of applying one fixed cutoff (co-26, co-15; Example 59, Example 62).

CREATE CONSTRAINT ... IS UNIQUE for the first requirement, and CREATE INDEX plus an EXPLAIN check confirming NodeIndexSeek (rather than a full label scan) for the second -- two different guarantees from two different statements (co-22; Example 20, Example 21).

Neo4j's ACID transaction guarantee: an exception raised anywhere inside execute_write's wrapped function rolls back every write already attempted in that same transaction, not just the failing one (co-19; Example 22).

Neo4j's per-node write locking. Two overlapping transactions writing the same node cannot both hold the lock simultaneously -- one is forced to fail with a catchable exception (or retry), never a silent lost update (co-19; Example 74).

neo4j-admin database import full, the offline, whole-database import path -- it writes storage files directly, bypassing the normal transactional write path, but only runs against a stopped, empty target (co-20; Example 24).

Prefix those specific queries with CYPHER 5 to pin them to the frozen dialect explicitly, regardless of whatever the database's own configured default becomes later (co-21; Example 52).

Identify the supernode by degree (COUNT { (n)--() }) and restructure the pattern to avoid routing through it unnecessarily -- either by matching through a narrower, more specific intermediate node instead, or, for a genuinely unavoidable supernode, refactoring its edges through an intermediate grouping node (co-17, co-04; Example 43, Example 44, Example 72).

// THE FIX: -[:FOLLOWS]-> (co-07) requires the SAME direction as the data was written
// with -- Cid's FOLLOWS edge points the OTHER way, so it no longer fits this pattern.
MATCH (a:Person {name: 'Ada'})-[:FOLLOWS]->(other:Person)
RETURN other.name
ORDER BY other.name;
 
// => only Bob -- Cid's edge points INTO Ada, not out of her, so it is correctly excluded

Root cause: An undirected pattern (a)--(b) (Example 9) matches a stored relationship from either endpoint's perspective -- Cid's [:FOLLOWS]-> edge into Ada satisfies (a)--(other) exactly as readily as Ada's own outgoing edge to Bob does, because dropping the arrowhead drops direction as a filtering criterion entirely. Restoring the arrowhead (-[:FOLLOWS]->) makes direction part of the pattern's shape again, exactly as Example 3 and Example 6 establish it, and Cid's reversed edge simply does not fit.

Run: cypher-shell < kata.cypher

Output:

+------------+
| other.name |
+------------+
| "Bob"      |
+------------+
1 row

// THE FIX: MERGE (co-06) matches a node that already exists instead of creating a
// second one -- rerunning the identical load twice still leaves exactly 2 nodes.
UNWIND ['Ada', 'Grace'] AS name
MERGE (:Person {name: name});
 
MATCH (p:Person)
RETURN count(p) AS person_count;
 
// => person_count is 2, not 4 -- the retry was a genuine no-op

Root cause: CREATE (Example 1) unconditionally writes the pattern every time it runs -- it has no way to know a matching node was already loaded by an earlier attempt, so a retried script simply doubles every row. MERGE (Example 10) matches the pattern first and only creates it if no match exists, which is exactly the idempotency a re-runnable loading script needs.

Run: cypher-shell < kata.cypher

Output:

+---------------+
| person_count  |
+---------------+
| 2             |
+---------------+
1 row

// THE FIX: OPTIONAL MATCH (co-05) preserves every row from the preceding MATCH,
// filling m with NULL wherever the DIRECTED pattern finds nothing.
MATCH (p:Person)
OPTIONAL MATCH (p)-[:DIRECTED]->(m:Movie)
RETURN p.name, m.title;
 
// => Ada's row now survives, with m.title = NULL

Root cause: A second plain MATCH behaves like Cypher's default inner-join semantics -- it requires the whole pattern chain, including this new clause, to find a match before any row survives (Example 27). Ada has zero DIRECTED edges, so the second MATCH finds nothing for her and her whole row disappears. OPTIONAL MATCH is the clause built specifically to keep the outer row regardless, filling the optional pattern's variables with NULL when nothing matches.

Run: cypher-shell < kata.cypher

Output:

+---------+-------------------+
| p.name  | m.title           |
+---------+-------------------+
| "Ada"   | NULL              |
| "Grace" | "Compile Error"   |
+---------+-------------------+
2 rows

// THE FIX: *1..2 (co-09) bounds the traversal depth inline -- unbounded * risks
// scanning the entire connected component, far past the "nearby" scope intended.
MATCH (a:Person {name: 'Ada'})-[:KNOWS*1..2]->(b:Person)
RETURN b.name
ORDER BY b.name;
 
// => only Bob (1 hop) and Cid (2 hops) -- Dee and Eve correctly fall outside the bound

Root cause: [:KNOWS*] with no upper bound (Example 14 warns against exactly this) traverses as many hops as the connected structure actually has, not the number of hops the query author had in mind -- on this 4-hop fixture it reaches every downstream node, and on a much larger, more densely connected production graph the same unbounded pattern could touch a very large fraction of the whole graph. *1..2 states the intended scope explicitly, so the traversal's cost and result size stay predictable regardless of how much further the underlying chain actually extends.

Run: cypher-shell < kata.cypher

Output:

+---------+
| b.name  |
+---------+
| "Bob"   |
| "Cid"   |
+---------+
2 rows

// THE FIX: CREATE CONSTRAINT (co-22) must exist BEFORE the duplicate write is
// attempted -- a constraint created afterward would not retroactively fix data
// that already violates it.
CREATE CONSTRAINT person_name FOR (p:Person) REQUIRE p.name IS UNIQUE;
 
CREATE (:Person {name: 'Ada'});
CREATE (:Person {name: 'Ada'});
// => the SECOND CREATE fails outright -- zero rows are ever duplicated

Root cause: Property graphs are schema-optional by default (Example 1) -- nothing stops two nodes from carrying an identical "unique" value unless a constraint says so explicitly (Example 20). The buggy script never runs CREATE CONSTRAINT, so both CREATE calls succeed and the database silently ends up with two nodes meant to be the one, canonical Ada. Creating the constraint first makes the second CREATE fail loudly and immediately instead.

Run: cypher-shell < kata.cypher

Output:

Neo.ClientError.Schema.ConstraintValidationFailed: Node(1) already exists with label
`Person` and property `name` = 'Ada'

def find_person_by_name(driver: Driver, name: str) -> list[str]:
    # THE FIX: $name is a bound parameter, not a splice point -- the driver sends
    # it to the engine as an opaque value, never as Cypher syntax.
    query = "MATCH (p:Person) WHERE p.name = $name RETURN p.name AS name"
    with driver.session() as session:
        result = session.run(query, name=name)
        return [row["name"] for row in result]
 
 
malicious_input: str = "nobody' OR '1'='1"
print(find_person_by_name(driver, malicious_input))  # => Output: [] (correctly zero matches)

Root cause: Building f"... WHERE p.name = '{name}'" makes the caller's input part of the CYPHER TEXT ITSELF -- a value crafted with an embedded ' OR '1'='1 does not just fail to match, it adds a real OR clause that makes the whole condition true for every row, the exact hazard the bound parameters used throughout this course's Python examples (Example 18's n=n, Example 44's name=name) are already written to avoid. A $name placeholder sends the value to the engine as a bound parameter, entirely separate from the query text, so no character sequence inside it can ever be interpreted as Cypher syntax.

Run: python3 kata.py (against a live Neo4j instance)

Verify (hand-reasoned, not a fabricated live-run capture -- this environment cannot execute a live Neo4j server): with $name bound as an opaque parameter, the query becomes WHERE p.name = "nobody' OR '1'='1" as a single literal string comparison -- no person in the fixture has that literal name, so the query must return the empty list:

[]

// THE FIX: match through GraphTeam (co-17, co-11) instead of AllStaff -- GraphTeam
// carries degree 2 in this fixture, AllStaff carries degree 20, so this pattern
// touches ten times FEWER relationships on this small fixture alone, and the gap
// only widens as the company grows while GraphTeam's own size stays fixed.
MATCH (a:Person {name: 'Ada'})-[:MEMBER_OF]->(grp:Group {name: 'GraphTeam'})<-[:MEMBER_OF]-(colleague:Person)
WHERE colleague <> a
RETURN colleague.name;
 
// => "Bob" -- correctly scoped to Ada's REAL team, not the entire company

Root cause: AllStaff is a supernode by construction -- every employee belongs to it, so its degree grows 1-to-1 with headcount, exactly the shape Example 43 identifies by degree count (co-17). Matching colleagues through it forces the query to enumerate all 20 of AllStaff's relationships to find every other member (co-04's index-free adjacency still applies, but the STARTING node's own degree is what the cost tracks), and returns nearly the whole company as "colleagues" in the process -- a correctness bug and a performance bug from the same root cause. GraphTeam, with degree 2 in this fixture, is both the narrower, semantically correct group to match through AND the cheaper one to traverse -- the same property-to-node promotion pattern Example 72 uses to mitigate a real supernode.

Run: cypher-shell < kata.cypher

Output:

+-----------------+
| colleague.name  |
+-----------------+
| "Bob"           |
+-----------------+
1 row

Index-free adjacency means each node stores direct pointers to its own relationships, so a hop's cost is a lookup local to that one node's own adjacency list, never a search across the whole database (Example 18). That is exactly the "deep-traversal performance is the specific win a graph database is built around" framing consistency-latency-throughput names for this course: latency for a k-hop query tracks the actual path walked, not the total stored volume. But the guarantee is scoped to "proportional to the node's OWN degree" -- it says nothing about how large that degree happens to be. A supernode with 50,000 relationships genuinely has 50,000 relationships to enumerate on a hop through it (Example 44); index-free adjacency's promise is about locality, not about a bound on any one node's own size, which is exactly why co-17's mitigation (Example 72) exists as a separate, deliberate structural fix rather than something index-free adjacency solves automatically.

coupling-vs-cohesion in this course names something deeper than syntax convenience: the domain a graph database models genuinely IS connectedness itself, not an incidental property of otherwise independent rows. A relational join table treats "Ada takes Graph Theory" as an accident of two independent entity tables needing to reference each other; a TAKES relationship treats the same fact as what it structurally is -- a first-class connection with its own identity and its own properties (Example 33, Example 34). The cohesion argument is that the relationship's shape in the model matches the relationship's shape in the real world directly, rather than being reconstructed at query time via a join that has to rediscover a connection the schema itself does not represent as one.

MERGE is fundamentally ambiguous about which of two very different things just happened -- did this statement just create brand-new data, or did it find data that was already there? Those two outcomes often need genuinely different follow-up actions: a first-seen timestamp only makes sense to set once, on creation, while a running "seen" counter only makes sense to increment on a repeat match (Example 11). A single unconditional SET after MERGE cannot express that distinction at all -- it would either stamp firstSeen on every rerun (wrong) or never increment seen (also wrong). ON CREATE/ON MATCH exist specifically because MERGE's two branches are semantically different operations that happen to share the same match-or-create entry point.

A property graph bundles a resource's facts into one addressable node object -- a label plus a bag of properties -- which is compact and ergonomic for pattern-matching within a single, self-contained database (Example 1, Example 64). RDF instead decomposes literally everything, including what a property graph calls a "property," into its own subject-predicate-object triple, with no single node object bundling a resource's facts together (Example 25, Example 78). Neither is more correct because they optimize for different things: RDF's uniform triple shape is what makes merging datasets from entirely different sources under a shared, standardized vocabulary straightforward (co-02), while the property graph's bundling trades that uniformity for more compact, more ergonomic pattern-matching within one database that was never meant to merge with an external, unrelated dataset at the triple level.

Independent rows, by definition, do not reference each other -- a customer row sharded by ID has no structural need to ever look at another shard, because nothing about that row's meaning depends on a different customer's row. A graph's entire reason for existing is the opposite: relationships are the actual data (coupling-vs-cohesion again), so any partition boundary drawn across a densely connected graph is very likely to slice through real relationships that were meaningfully connecting two now-separated pieces (Example 45). Every one of those cut relationships becomes a network round trip at query time instead of a local pointer follow -- which is exactly why community-aware sharding (Example 73) is worth the extra work: it draws the boundary along the graph's own naturally sparse seams instead of an arbitrary id range.

Evolving Cypher's syntax in place would mean every existing query, application, and script written against the old syntax could silently start behaving differently -- or fail outright -- the moment the database engine itself upgraded, with no way to opt out. Freezing Cypher 5 (bug-fixes only) alongside an evolving Cypher 25 (Example 15, Example 79) lets existing code keep behaving identically indefinitely, while new code deliberately opts into the evolving, GQL-aligned dialect via the CYPHER 25 prefix or a new database's own default (Example 52, Example 53). The cost is that two dialects now coexist, and any course or reference material touching version-sensitive syntax has to say explicitly which one it targets, rather than assuming one unversioned "Cypher" the way older material could. (Cypher 5/Cypher 25 are the current dialect names at the time this course was written -- see the course overview's dated Accuracy notes.)