Query Languages
May 12, 2026
GQL vs. Cypher: What the New ISO Standard Brings to the Table
NebulaGraph
When the ISO published GQL in 2024, the graph community took notice. Yet for many developers today, the language they know best isn't GQL; it's Cypher or openCypher.
These languages share far more than they differ. GQL, built directly upon Cypher's foundation, and today's Cypher implementations are actively converging toward GQL compliance. As Neo4j CTO Philip Rathle put it: "If you're already using Cypher or openCypher, then you're already 95% there."
With GQL now established as the official ISO standard, the natural question arises: What does GQL offer that Cypher doesn't? How steep is the learning curve? And what does it take to migrate existing Cypher workloads?
This post explores what GQL brings beyond Cypher, and why the upgrade is worth it.
Understanding the Landscape: GQL, Cypher, and openCypher
Before diving into comparisons, let's clarify what each language represents.
Cypher: The Proven Foundation
Cypher emerged in 2011, developed by Neo4j, with a clear design philosophy: emulate SQL where possible, innovate only where necessary. It introduced the now-familiar ASCII-art syntax (node)-[edge]->(otherNode) and a declarative approach that lets users describe what to find, not how to find it. Over the following decade, Cypher became the overwhelming de facto standard for property graph query languages.
openCypher: The Community Specification
In 2015, Neo4j launched the openCypher project, open-sourcing Cypher's specification, documentation, tests, and code artifacts to help other vendors implement the language. This initiative proved highly successful: today, more than a dozen graph databases and dozens of tools support openCypher, establishing it as the common language across the graph ecosystem.
GQL: The Official ISO Standard
As an ISO standard, GQL (Graph Query Language, ISO/IEC 39075) offers:
Formal specification: Rigorously defined by the same committee that oversees SQL
Comprehensive feature set: Read-write capabilities, schema management, and advanced path patterns
Vendor neutrality: A consistent language across compliant implementations
How They Relate
It is important to understand that GQL did not emerge in isolation. The ISO committee drew inspiration from several existing languages, with Cypher and openCypher being the most significant influences. GQL has adopted much of Cypher's query construction semantics, including the MATCH/RETURN format.
Why Standardization Matters: The ISO Committee Behind GQL
The Same Committee That Oversees SQL
GQL was developed by ISO/IEC JTC1 SC32 WG3—the same international committee responsible for developing and maintaining the SQL standard. This committee comprises national standards bodies from around the world, with participants appointed through formal government processes. When a language is standardized by this body, it carries the same weight and long-term commitment as SQL.
Standardization brings concrete benefits:
Portability: Queries written in GQL will work across compliant implementations, reducing vendor lock-in and preserving your investment in graph expertise.
Clarity: A formally specified language leaves less room for vendor-specific variations and undocumented behavior.
Ecosystem growth: Shared language means shared tools, shared learning resources, and a broader community.
As the ISO itself states, the GQL standard is designed to "provide capabilities for creating, accessing, querying, maintaining, and controlling property graphs"—a complete, vendor-neutral foundation for the graph database industry.
ISO Standard vs. Vendor Language: A Real-World Analogy
To understand why the distinction matters, consider it this way:
Cypher and openCypher are like a de facto standard—widely adopted, well-understood, and proven in production across many systems. The majority of graph database users write queries in Cypher every day, and its value is undeniable.
GQL is like an official standard—formally specified, internationally recognized, and designed for long-term stability across the entire industry, not just one vendor's ecosystem. It represents a commitment that no single company can change on its own.
Both have their place. But for organizations making long-term architectural decisions, the ISO standard offers a level of guarantees that a vendor-sourced language cannot provide.
This is not to diminish the value of openCypher—quite the opposite. openCypher has been remarkably successful, and it continues to play a crucial role in the ecosystem. The key point is that the direction of the industry is clear: the openCypher specification is now evolving toward GQL compliance by progressively integrating GQL features.
GQL vs. Cypher: Key Enhancements in GQL
While the similarities between GQL and Cypher are substantial, GQL introduces several important enhancements that make queries more explicit, efficient, and expressive. GQL simplifies deployment architectures and reduce operational overhead while supporting queries that are cleaner, less error-prone, and easier to maintain.
Advanced Pattern Matching
Regex-like variable-length patterns. GQL introduces syntax familiar to developers from regular expressions:
-[e]->{1,3}, -[e]->+, -[e]->*, and -[e]->?. This offers greater flexibility than Cypher's [*min..max] notation.
Path restrictors. GQL provides four path restrictors—WALK, TRAIL, ACYCLIC, and SIMPLE—to control whether paths can have repeated nodes or edges. This level of control is invaluable in domains like fraud detection, where you might need to find all paths without cycles, or network analysis where edge repetition would indicate invalid routes.
WALK: Allows repeated nodes and edges (default behavior)
TRAIL: Prevents repeated edges, but allows repeated nodes
ACYCLIC: Prevents repeated nodes
SIMPLE: Prevents repeated nodes and edges
For a concrete example: in anti‑money laundering (AML) investigations, you need to trace funds across accounts without ever reusing an edge—because revisiting the same transaction would invalidate the audit trail. Cypher has no built‑in way to enforce edge uniqueness across a path; you would have to write complex post‑processing or recursive logic. With GQL's TRAIL restrictor, the query MATCH TRAIL p = (a:Account)-[t:TRANSFER]->+(b:Account) ...guarantees edge‑distinct paths natively, delivering audit‑ready results that are impossible to achieve cleanly in Cypher alone.
Path selectors. GQL offers dedicated shortest-path syntax: ANY SHORTEST, ALL SHORTEST, and SHORTEST k. This built-in capability eliminates the need for complex workarounds that Cypher users often have to implement.
The LET Statement: A New Way to Define Variables
One of GQL's practical enhancements is the introduction of the LET statement. To understand its value, it helps to first recall how variable definition works in Cypher.
In Cypher, the WITH clause serves two purposes: it passes results from one part of a query to the next, and it also allows you to define new aliases or variables. However, WITH is blocking — when you use it, you must explicitly list all existing variables that you want to keep in scope. Forgetting a variable means it becomes unavailable in subsequent clauses.
Cypher
GQL adds a more lightweight way: LET.
LET defines a variable without disrupting the current stream of bindings. It simply adds a new column to the result set, leaving all existing variables untouched and in scope. This is especially useful for intermediate calculations or aliasing long expressions.
GQL
In this example, u, v, and f remain accessible automatically — no need to repass them through a WITH clause. The query is cleaner, less error‑prone, and easier to maintain, especially as complexity grows.
Beyond Syntax: Key Missing Pieces GQL Adds
Standardized Graph Concepts
One long-standing challenge in the graph database industry has been inconsistent terminology across products. This lack of common vocabulary creates confusion for developers moving between databases and complicates efforts to write portable queries.
GQL solves this by providing a standardized data model and terminology. It formally defines core concepts such as:
Node (or Vertex): An entity in the graph
Edge (or Relationship): A directed connection between two nodes
Label: A tag assigned to a node (nodes can have multiple labels)
Property: A key-value pair attached to nodes or edges
Type: A named category for edges (e.g.,
:FOLLOWS,:TRANSFERS_TO)
Closed Graph Types: DDL for Graphs
Cypher has historically lacked schema definition capabilities. Users could create nodes and edges without explicitly defining their structure, which offers flexibility but becomes problematic in production environments where data governance, validation, and performance optimization matter. The absence of a proper Data Definition Language (DDL) has been a notable limitation for enterprise adopters.
GQL introduces closed graph types (also known as fixed-schema graphs). This allows you to explicitly define the structure of a graph before populating it.
Once a graph is created with a closed type, all insertions and updates must conform to the defined schema. This brings several benefits:
Data validation at insertion time — prevents malformed data from entering the system
Performance optimizations — the database can plan storage and indexes based on known structure
Clear documentation — the schema serves as executable documentation
Migration safety — changes can be managed systematically
Closed graph types are increasingly important in enterprise production environments, where they deliver greater security and stability.
Multi‑Graph Support
In Cypher, you typically work within a single graph database at a time. Managing multiple graphs for different applications, tenants, or test environments often requires separate database instances or cumbersome namespace conventions.
GQL natively supports multiple graphs within a single database session. You can create, switch between, and query distinct graphs independently.
This capability is particularly useful for:
Multi‑tenancy: Each tenant can have its own isolated graph
Environment separation: Development, staging, and production graphs coexist
Workload isolation: Analytical queries run on a copy graph without impacting transactional graphs
Multi‑graph support simplifies deployment architectures and reduces operational overhead.
Undirected Edges
Cypher has always treated edges as directed. While this aligns with many use cases (e.g., “A follows B”), there are scenarios where direction is either irrelevant or explicitly undesired. Examples include:
A friendship between two people
A chemical bond between two atoms
A road connecting two intersections
A co‑authorship relationship
In Cypher, you must query both directions or use a trick (e.g., omitting arrow direction in patterns), but the underlying storage and semantics remain directed.
GQL introduces true undirected edges. When you define an edge, you can specify that it has no inherent direction.Querying undirected edges is intuitive—you do not need to handle two directions manually.
Undirected edges simplify both modeling and querying for symmetric relationships, making the graph more accurately reflect the real‑world domain.
A Smooth Transition: Moving from Cypher to GQL
For teams currently using Cypher (or openCypher), transitioning to GQL is not a rewrite—it is an upgrade. Here is what you need to know.
Minimal Learning Curve
The learning curve is surprisingly gentle. Many basic queries are identical in both languages. The most notable syntactic differences include:
Feature | Cypher | GQL |
Variable-length paths |
|
|
Creating nodes/edges |
|
|
Unwinding lists |
|
|
Variable definition |
|
|
These differences are not fundamental changes—they are refinements. Existing knowledge transfers directly.
What About Existing Applications?
For production systems running Cypher queries today, the migration path is straightforward in principle—the openCypher specification is explicitly evolving toward GQL compliance. For practical steps, building a migration strategy depends on factors including:
The specific graph database platform you are using
The volume and complexity of existing queries
The vendor's GQL support roadmap and compatibility guarantees
For organizations using NebulaGraph, this transition is particularly straightforward: the Enterprise Edition is designed with native GQL support at the architecture level, meaning queries can be migrated incrementally with clear compatibility.
NebulaGraph and the GQL Standard
NebulaGraph's journey with GQL reflects our commitment to open standards and our belief that standardized query languages benefit the entire graph community. As a member of the Linked Data Benchmark Council (LDBC), Vesoft (the team behind NebulaGraph) has actively participated in the development and promotion of the GQL standard, contributing insights from building and operating one of the world's most scalable distributed graph databases.
NebulaGraph Enterprise Edition is the first distributed graph database to implement native GQL support. This offers several advantages:
Superior data compatibility
Simplified system architecture with less likelihood of errors and easier operation and maintenance
Mature security controls without requiring additional development layers
Reduced future maintenance costs as the GQL standard continues to evolve
Conclusion: Evolution, Not Revolution
The arrival of GQL as an ISO standard is not a disruptive event that forces developers to learn an entirely new language. It is the culmination of years of practical experience with Cypher, openCypher, and other graph query languages—refined, standardized, and secured for long-term industry-wide adoption.
For developers, the message is simple: if you know Cypher, you already know most of GQL. What GQL adds is standardization, portability, and thoughtful enhancements like LET and path restrictors that make complex queries easier to write and maintain.
As you explore GQL further, you'll discover that you're adopting a standard that will shape how you work with connected data for years to come—and that journey starts with the tools available today.
Ready to experience GQL in production? Explore how NebulaGraph Enterprise implements the GQL standard and start writing queries that match how you think about connected data.
Read More:
