In January 2025 Neo4j stopped numbering releases 5.x and shipped Neo4j 2025.01. In June it added a second Cypher language version, Cypher 25, that sits beside Cypher 5 in the same server. And underneath both sits GQL, the ISO/IEC 39075 standard for graph query languages published in 2024, which Cypher 25 is designed to align with. Three changes, announced quietly, that together alter how a team should run Neo4j in production. This post explains what each means and what we tell clients to do about them.
Calendar versioning: YYYY.MM.patch
Neo4j versions are now dates. 2026.05.0 is the May 2026 release; a 2026.05.1 would be a patch to it. Releases ship roughly monthly, and each one is a full release — new features, fixes, and occasionally behavioural changes — rather than the feature-frozen patch stream you were used to on 4.4 or 5.26.
What changes for you:
- Support is rolling. There is no "2025.x LTS". Each CalVer release is supported for a defined window after the next one ships; the practical consequence is that staying supported means upgrading a few times a year at minimum.
- 5.26 remains the LTS. If you need a version to sit on for years, 5.26 is it, supported until June 2028. The CalVer line is for teams that want features as they land.
- Upgrades within the line are rolling. On an Autonomous Cluster you upgrade one server at a time with no downtime; store formats are forward-compatible within the line. This is what makes monthly cadence feasible.
- 4.4 → 2025.x is not a single hop. 4.4 must go to 5.26 first, as covered in our 90-day migration plan.
How to pin versions in production
Do not run neo4j:latest, in Docker or anywhere else. Pin the full version — neo4j:2026.05.0-enterprise, a specific package version in your OS repo, a specific AMI — and promote the same artifact through dev, staging, and production. Aura manages this for you; self-managed teams should treat the monthly release like any other dependency with a changelog to read.
The policy we recommend
Pick one of two, and write it down:
- LTS policy: run 5.26 until a business reason (a feature, a driver requirement, a GenAI project) forces a move. Review annually. Upgrade to the next LTS when it is announced.
- Current policy: run the CalVer line, upgrading quarterly to the latest release, monthly if a patch addresses something you hit. Keep a staging cluster one release ahead of production to absorb surprises.
What does not work is the middle path — moving to 2025.03, then forgetting about it. Within a year that is an unsupported version again, and you have the 4.4 problem back with a newer number.
Cypher 25: a second language version, not a breaking change
Since 2025.06, every database can run queries in Cypher 5 or Cypher 25. Cypher 5 is the default and is the dialect all your existing code is written in. Cypher 25 is where new syntax lands and where the deprecations Neo4j has been warning about for years finally take effect.
You choose per query with a prefix:
CYPHER 25
MATCH (p:Person)
LET age = 2026 - p.born
FILTER age >= 18
RETURN p.name, age;
Or per database, so applications inherit it:
ALTER DATABASE neo4j SET DEFAULT LANGUAGE CYPHER 25;
Highlights of what Cypher 25 adds or tightens (see the Cypher 25 manual):
LETto bind expressions without theWITH *dance, andFILTERas a standalone clause.- Conditional queries (
WHEN ... THEN ... ELSE) andNEXTfor linear query composition, both from the GQL standard. - Quantified path patterns as the preferred way to express variable-length traversals, with better planning than
*1..n. - The native Vector type (2025.10+) and its functions, for embeddings stored as real vectors rather than lists of floats.
- Removal of long-deprecated syntax — the things the Cypher 5 deprecations page has flagged: legacy
exists(), certain pattern expressions, old index creation syntax.
The important operational point: nothing breaks until you opt in. A database defaulting to Cypher 5 runs exactly as it did. Switch the default only after running your query corpus through Cypher 25 on a staging copy. Teams with a large legacy codebase typically leave the default at 5 and prefix new work with CYPHER 25; greenfield projects start on 25 and never look back.
GQL: why any of this is happening
GQL (ISO/IEC 39075:2024) is the first new ISO database language standard since SQL. Neo4j was a principal contributor, and Cypher — openCypher before it — is the closest ancestor of the standard's syntax. Cypher 25 is Neo4j's vehicle for GQL conformance: the GQL-defined constructs (LET, FILTER, conditional queries, NEXT, the graph type model) arrive in Cypher 25, and the Cypher-specific leftovers that conflict with GQL go out.
For a team this matters in two ways. First, skills and code become more portable as other vendors implement GQL. Second, the standard has a formal notion of conformance, so "we write standard GQL where possible" is now a meaningful architectural guideline — one worth adopting for new code even if you never leave Neo4j.
What to do this quarter
- Know your version and its support date. If it is 4.4, start the migration now. If it is 5.x but not 5.26, move to 5.26 — a minor upgrade.
- Write the version policy (LTS or current) and put the next upgrade on the calendar.
- Pin artefacts; ban
latest. - Upgrade drivers to 6.x in the applications you actively develop.
- Run your query corpus under
CYPHER 25on staging and triage the failures. Most are mechanical. - Start new code on Cypher 25 and treat GQL-standard syntax as the default choice.
If you would like a second opinion on which policy fits your estate, or hands to do the query sweep, contact us.