Cypher Query Language
Also known as: openCypher, Neo4j Cypher, graph query language
- Cypher Query Language
- Cypher is a declarative pattern-matching language for property graphs. Created at Neo4j in 2011 and opened via openCypher in 2015, it became the primary input dialect of the ISO/IEC 39075:2024 GQL standard. It expresses graph traversals as ASCII-art patterns rather than imperative code.
Cypher is a declarative graph query language for matching patterns in property graphs, used to retrieve nodes and relationships from databases like Neo4j and standardized as the basis of ISO/IEC 39075:2024 GQL.
What It Is
Querying a graph database imperatively is painful. You would have to write loops to walk relationships, track visited nodes by hand, and assemble the result set yourself — every traversal becomes a small graph algorithm written from scratch. Cypher exists so you don’t have to. It lets you describe the pattern you want as a small drawing in text — nodes in parentheses, relationships as arrows — and the database figures out how to walk the graph for you. For anyone building a knowledge graph RAG pipeline, that translation from picture to query is the thing that makes graph retrieval feasible at all.
A Cypher query is built from a few core verbs. MATCH finds patterns. CREATE writes new nodes and relationships. MERGE combines the two — match if it exists, otherwise create. SET updates properties, DELETE removes data. The pattern itself uses ASCII-art notation: (person:Person)-[:WORKS_AT]->(company:Company) reads as a person who works at a company, with the labels and relationship type written exactly as they live in the graph. The language is declarative — you describe the shape you want returned, and the planner picks the traversal order.
What changed recently matters for anyone choosing a graph database in 2026. According to Neo4j Blog, ISO/IEC 39075:2024 GQL was ratified on 11 April 2024 — the first new ISO database language since SQL in 1987 — and Cypher is its primary input dialect. According to Neo4j Cypher Manual, Neo4j 5 and the 2026.x release line ship progressive GQL conformance for clauses like MATCH, CREATE, MERGE, SET, and DELETE, and the Neo4j 2026.01 release added a SEARCH clause that makes native vector indexes queryable from Cypher directly. That is why GraphRAG pipelines now treat Cypher as a retrieval surface, not just a write path.
How It’s Used in Practice
The most common encounter with Cypher in 2026 is inside a knowledge graph RAG pipeline. A user asks a question, the application picks an entry node in the graph — by name, ID, or vector similarity — and uses Cypher to walk outward. Two or three hops along specific relationship types pull the starting entity, its neighbors, and the community summaries that explain the cluster it belongs to. The result is a subgraph rather than a flat list of chunks, which is what gives GraphRAG the ability to answer multi-hop questions plain vector RAG cannot.
A typical retrieval reads: MATCH a starting node, traverse along named relationship types, RETURN the nodes and relationship metadata. The application stitches that subgraph into the language model prompt as structured context. Teams running hybrid pipelines now combine this with the SEARCH clause for vector lookup so a single Cypher query handles both semantic similarity and graph traversal in one round trip.
Pro Tip: When GraphRAG returns too much noise, add a LIMIT and tighten the relationship-type list before you tune the embedding model. Most “graph retrieval returned the wrong thing” problems are over-broad Cypher patterns, not bad embeddings.
When to Use / When Not
| Scenario | Use | Avoid |
|---|---|---|
| Multi-hop retrieval for a knowledge graph RAG pipeline | ✅ | |
| Aggregations over flat, unrelated tabular rows | ❌ | |
| Schema-flexible exploration when relationships matter more than columns | ✅ | |
| High-volume row-by-row analytics across unrelated entities | ❌ | |
| Building a GraphRAG retrieval surface that mixes pattern matching with vector search | ✅ | |
| Replacing an OLAP warehouse for reporting workloads | ❌ |
Common Misconception
Myth: Cypher is a proprietary Neo4j-only language, so adopting it locks you into one vendor. Reality: According to the openCypher project, the language has been open since October 2015, and according to Neo4j Blog, it became the primary input dialect of the ISO/IEC 39075:2024 GQL standard ratified on 11 April 2024. Cypher patterns are now supported across multiple graph databases including Memgraph, RedisGraph, and Amazon Neptune via openCypher.
One Sentence to Remember
If your retrieval problem is shaped like “follow the relationships,” Cypher is the language that lets you say so directly — and as of GQL standardization, that skill travels across graph vendors.
FAQ
Q: Is Cypher only for Neo4j? A: No. According to the openCypher project, the language has been open since 2015, and it now underpins the ISO/IEC 39075:2024 GQL standard implemented by multiple graph databases including Memgraph, RedisGraph, and Amazon Neptune.
Q: How is Cypher different from SQL? A: SQL operates on tables and joins; Cypher operates on patterns of nodes and relationships. A multi-hop traversal that takes a few lines of Cypher typically requires nested joins or recursive CTEs in SQL.
Q: Can I use Cypher for vector search inside a GraphRAG pipeline?
A: Yes. According to Neo4j Cypher Manual, Neo4j 2026.01 introduced the SEARCH clause for vector-index queries, making Cypher a hybrid retrieval surface that combines graph traversal with semantic similarity in one query.
Sources
- Neo4j Cypher Manual: Cypher Manual — Neo4j Docs - Official reference for Cypher syntax, clauses, and GQL conformance notes.
- openCypher project: openCypher — open specification of Cypher - Open specification of the Cypher property graph query language.
Expert Takes
Cypher’s elegance comes from a single insight: a query should look like the structure it returns. The arrow notation mirrors how a graph is drawn on a whiteboard — nodes in parentheses, relationships as arrows. That visual isomorphism is not decoration. It collapses the distance between modelling and querying, which is why pattern-matching languages generalize cleanly into standards. The shape of the query is the shape of the answer.
Cypher works because the database carries the schema and Cypher carries the intent. You describe the pattern you want, the planner picks the traversal order. For specification-driven retrieval that means your query stays close to your domain model — the Cypher itself reads as documentation of what the pipeline expects. In a GraphRAG pipeline, those patterns become the contract between knowledge graph and language model. Clear contract, clear retrieval.
Graph query languages were a fragmented market until standardization changed the calculus. Once Cypher became the basis of an ISO database standard, pattern matching stopped being vendor lock-in and started being a portable skill. That matters because GraphRAG depends on retrieval staying movable across vendors. Teams shopping for graph databases now ask one question first: does it speak the standard. The vendors that ignored it are losing RFPs to ones that didn’t.
A query language shapes what its users think to ask. Cypher makes traversal cheap and intuitive, which is a gift — but also a trap. When walking the graph feels effortless, you stop questioning whether the graph itself is honest. Who decided which entities deserve a node? Which relationships were inferred by an extractor that may have hallucinated? The language is neutral. The graph it queries rarely is.