neo4j · JPryce-Aklundh · Sep 2, 2025 · Jun 18, 2025 · Jun 18, 2025 · Jun 18, 2025
diff --git a/antora.yml b/antora.yml
@@ -7,4 +7,4 @@ nav:
 - modules/ROOT/content-nav.adoc
 asciidoc:
   attributes:
-    neo4j-version: '2025.07'
+    neo4j-version: '2025.08'
diff --git a/modules/ROOT/images/graph-predicate-functions.svg b/modules/ROOT/images/graph-predicate-functions.svg
diff --git a/modules/ROOT/images/predicate-function-example.svg b/modules/ROOT/images/predicate-function-example.svg
diff --git a/modules/ROOT/pages/clauses/listing-functions.adoc b/modules/ROOT/pages/clauses/listing-functions.adoc
@@ -254,19 +254,17 @@ WHERE name STARTS WITH 'a'
 |===
 | name    | isBuiltIn
 
-| "abs"   | true
-| "abs"   | true
-| "acos"  | true
-| "all"   | true
-| "any"   | true
-| "asin"  | true
-| "atan"  | true
+| "abs" | true
+| "acos" | true
+| "all" | true
+| "allReduce" | true
+| "any" | true
+| "asin" | true
+| "atan" | true
 | "atan2" | true
-| "avg"   | true
-| "avg"   | true
-| "avg"   | true
+| "avg" | true
 
-2+d|Rows: 11
+2+d|Rows: 9
 |===
 
 

diff --git a/modules/ROOT/pages/clauses/match.adoc b/modules/ROOT/pages/clauses/match.adoc
@@ -639,10 +639,26 @@ RETURN relationshipType, count(r) AS relationshipCount
 [[dynamic-match-caveats]]
 === Performance caveats
 
-`MATCH` queries using dynamic values may not be as performant as those using static values.
-This is because the xref:planning-and-tuning/execution-plans.adoc[Cypher planner] uses statically available information when planning queries to determine whether to use an xref:indexes/search-performance-indexes/index.adoc[index] or not, and this is not possible when using dynamic values.
+`MATCH` queries that use dynamic values may not perform as well as those with static values.
+Neo4j is actively working to improve the performance of these queries.
+The table below outlines performance caveats for specific Neo4j versions.
 
-As a result, `MATCH` queries using dynamic values cannot leverage xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead use the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly.
+.Neo4j versions and performance caveats
+[%header,cols="a,5a"]
+|===
+| Neo4j versions | Performance caveat
+
+| 5.26 -- 2025.07
+| The xref:planning-and-tuning/execution-plans.adoc[Cypher planner] is not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. 
+
+| 2025.08 -- current
+| The Cypher planner is able to leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically.
+This is enabled by the introduction of three new query plan operators: 
+xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-label-node-lookup[`DynamicLabelNodeLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`].
+It is not, however, able to use indexes on property values.
+For example, `MATCH (n:$(Label) {foo: bar})` will not use any indexes on `n.foo` but can use a `DynamicLabelNodeLookup` on `$(label)`.
+
+|===
 
 [[further-reading]]
 === Further reading

diff --git a/modules/ROOT/pages/clauses/merge.adoc b/modules/ROOT/pages/clauses/merge.adoc
@@ -740,42 +740,23 @@ RETURN greta.name AS name, labels(greta) AS labels, type(rel) AS relType, collec
 [[dynamic-merge-caveats]]
 === Performance caveats
 
-`MERGE` queries that use dynamic values may not be as performant as those using static values.
-This is because the xref:planning-and-tuning/execution-plans.adoc[Cypher planner] uses statically available information when planning queries to determine whether to use an xref:indexes/search-performance-indexes/index.adoc[index] or not, and this is not possible when using dynamic values.
+`MERGE` queries that use dynamic values may not perform as well as those with static values.
+Neo4j is actively working to improve the performance of these queries.
+The table below outlines performance caveats for specific Neo4j versions.
 
-As a result, `MERGE` queries with dynamic values cannot leverage xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead use the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly.
-
-To circumvent possible performance issues, place the dynamic labels or relationship types within `ON CREATE` or `ON MATCH` subclauses.
-
-.Parameters
-[source, parameters]
-----
-{
-    "onMatchLabels": ["Filmmaker", "AwardRecipient"],
-    "onCreateLabels":  ["ScreenWriter", "AwardWinner"]
-}
-----
-
-.Merge nodes using dynamic values in `ON CREATE` and `ON MATCH` subclauses
-[source, cypher]
-----
-MERGE (n:Person {name: "Greta Gerwig"}) 
-ON MATCH 
-    SET n:$($onMatchLabels)
-ON CREATE 
-    SET n:$($onCreateLabels)
-RETURN labels(n) AS gretaLabels
-----
-
-Because a `Person` node with the `name` "Greta Gerwig" already exists, this query will only `SET` the dynamic labels added to the `ON MATCH` subclause.
-
-.Result
-[role="queryresult",options="footer",cols="1*<m"]
+.Neo4j versions and performance caveats
+[%header,cols="a,5a"]
 |===
-| gretaLabels
+| Neo4j versions | Performance caveat
 
-| ["Person", "Director", "Filmmaker", "AwardRecipient"]
+| 5.26 -- 2025.07
+| The xref:planning-and-tuning/execution-plans.adoc[Cypher planner] is not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. 
 
-1+d|Rows: 1 
-|===
+| 2025.08 -- current
+| The Cypher planner is able to leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically.
+This is enabled by the introduction of three new query plan operators: 
+xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-label-node-lookup[`DynamicLabelNodeLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`].
+It is not, however, able to use indexes on property values.
+For example, `MERGE (n:$(Label) {foo: bar})` will not use any indexes on `n.foo` but can use a `DynamicLabelNodeLookup` on `$(label)`.
 
+|===
diff --git a/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc b/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc
@@ -22,6 +22,79 @@ Cypher 25 was introduced in Neo4j 2025.06 and can only be used on Neo4j 2025.06+
 Features removed in Cypher 25 are still available on Neo4j 2025.06+ databases either by prepending a query with `CYPHER 5` or by having Cypher 5 as the default language for the database.
 For more information, see xref:queries/select-version.adoc[].
 
+[[cypher-deprecations-additions-removals-2025.08]]
+== Neo4j 2025.08
+
+=== Updated in Cypher 25
+
+[cols="2", options="header"]
+|===
+| Feature
+| Details
+
+a|
+label:functionality[]
+label:updated[]
+[source, cypher]
+----
+MATCH (p:Product) WHERE p.name <> "Coffee"
+CALL (p) {
+    MATCH (p)<-[:BUYS]-(c:Customer)-[:BUYS]->(otherProduct)
+    RETURN c, otherProduct
+    NEXT
+    RETURN count(DISTINCT c) AS customers, 0 AS customersAlsoBuyingCoffee
+    UNION
+    FILTER otherProduct.name = "Coffee"
+    RETURN 0 as customers, count(DISTINCT c) AS customersAlsoBuyingCoffee
+    NEXT
+    RETURN max(customers) AS customers, max(customersAlsoBuyingCoffee) AS customersAlsoBuyingCoffee
+}
+RETURN p.name AS product,
+       round(toFloat(customersAlsoBuyingCoffee) * 100 / customers, 1) AS percentageOfCustomersAlsoBuyingCoffee
+  ORDER BY product
+----
+
+| `NEXT` now correctly supports aggregations in the context of `UNION` and `CALL`.
+For more information, see xref:queries/composed-queries/sequential-queries.adoc#issues-fixes[Sequential queries (`NEXT`) > Known issues and fixes].
+
+a|
+label:functionality[]
+label:updated[]
+[source, cypher]
+----
+PROFILE 
+WITH "Person" AS label
+MATCH (people:$(label))
+RETURN people.name
+----
+
+| Cypher can now leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when planning queries with xref:clauses/match.adoc#dynamic-match[dynamic labels and relationship types].
+This is enabled by the introduction of three new query plan operators: xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-label-node-lookup[`DynamicLabelNodeLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`].
+|===
+
+=== New in Cypher 25
+
+[cols="2", options="header"]
+|===
+| Feature
+| Details
+
+a|
+label:functionality[]
+label:new[]
+[source, cypher, role="noheader"]
+----
+MATCH (()-->(n))+
+WHERE allReduce(acc = 0, node IN n \| acc + node.x, 6 < acc < 30)
+RETURN [i IN n \| i.x] AS sequence 
+ORDER BY head(n).x, size(n)
+----
+
+| New xref:functions/predicate.adoc#functions-allreduce[`allReduce()`] function.
+It enables the stepwise evaluation of a value accumulated over a path, allowing for early pruning of paths that do not satisfy a given predicate, and is optimized for path expansions.
+|===
+
+
 [[cypher-deprecations-additions-removals-2025.07]]
 == Neo4j 2025.07
 

diff --git a/modules/ROOT/pages/functions/index.adoc b/modules/ROOT/pages/functions/index.adoc
@@ -373,7 +373,12 @@ These functions return either true or false for the given arguments.
 1.1+| xref::functions/predicate.adoc#functions-all[`all()`]
 | `all(variable :: ANY, list :: LIST<ANY>, predicate :: ANY) :: BOOLEAN`
 | Returns true if the predicate holds for all elements in the given `LIST<ANY>`.
-
+
+1.1+| xref::functions/predicate.adoc#functions-allreduce[`allReduce()`]
+| `allReduce(accumulator = initial, stepVariable IN list \| reductionFunction, predicate) :: BOOLEAN`
+| Returns true if, during the stepwise evaluation of a value across the elements in a given `LIST<ANY>`, the accumulated result satisfies a specified predicate at every step.
+Where that list is a group variable defined in a quantified path pattern, it allows for the early pruning of paths that do not satisfy the predicate. label:cypher[Cypher 25 only] label:new[Introduced in Neo4j 2025.08]
+
 1.1+| xref::functions/predicate.adoc#functions-any[`any()`]
 | `any(variable :: ANY, list :: LIST<ANY>, predicate :: ANY) :: BOOLEAN`
 | Returns true if the predicate holds for at least one element in the given `LIST<ANY>`.