Graph Query Language
GQL is a standardized query language for property graphs first described in ISO/IEC 39075, released in April 2024 by ISO/IEC.
History
The GQL project is the culmination of converging initiatives dating back to 2016, particularly a private proposal from Neo4j to other database vendors in July 2016, and a proposal from Oracle technical staff within the ISO/IEC JTC 1 standards process later that year.2019 GQL project proposal
In September 2019 a proposal for a project to create a new standard graph query language was approved by a vote of national standards bodies which are members of ISO/IEC Joint Technical Committee 1. JTC 1 is responsible for international Information Technology standards. GQL is intended to be a declarative database query language, like SQL.The 2019 GQL project proposal states:
Official ISO standard
The GQL standard, ISO/IEC 39075:2024 Information technology – Database languages – GQL, was officially published by ISO on12 April 2024.
GQL project organisation
The GQL project is led by and . They are also the editors of the initial early working drafts of the GQL specification.As originally motivated, the GQL project aims to complement the work of creating an implementable normative natural-language specification with supportive community efforts that enable contributions from those who are unable or uninterested in taking part in the formal process of defining a JTC 1 International Standard. In July 2019 the Linked Data Benchmark Council agreed to become the umbrella organization for the efforts of community technical working groups. The Existing Languages and the Property Graph Schema working groups formed in late 2018 and early 2019 respectively. A working group to define formal denotational semantics for GQL was proposed at the third GQL Community Update in October 2019.
ISO/IEC JTC 1/SC 32 WG3
Seven national standards bodies have nominated national subject-matter experts to work on the project, which is conducted by Working Group 3 of ISO/IEC JTC 1's Subcommittee 32, usually abbreviated as ISO/IEC JTC 1/SC 32 WG3, or just WG3 for short. WG3 has been responsible for the SQL standard since 1987.ISO stages
| date | ISO stages |
| 2019-09-10 | 10.99 New project approved |
| 2019-09-10 | 20.00 New project registered in TC/SC work programme |
| 2021-11-22 | 30.00 Committee draft registered |
| 2021-11-23 | 30.20 CD study initiated |
| 2022-02-25 | 30.60 Close of comment period |
| 2022-08-29 | 30.92 CD referred back to Working Group |
| 2022-08-29 | 30.00 Committee draft registered |
| 2022-08-30 | 30.20 CD study initiated |
| 2022-10-26 | 30.60 Close of comment period |
| 2023-03-22 | 30.99 CD approved for registration as DIS |
| 2023-03-24 | 40.00 DIS registered |
| 2023-05-24 | 40.20 DIS ballot initiated: 12 weeks |
| 2023-08-17 | 40.60 Close of voting |
| 2023-11-28 | 40.99 Full report circulated: DIS approved for registration as FDIS |
| 2023-12-11 | 50.00 Final text received or FDIS registered for formal approval |
| 2024-01-26 | 50.20 Proof sent to secretariat or FDIS ballot initiated: 8 weeks |
| 2024-03-23 | 50.60 Close of voting. Proof returned by secretariat |
| 2024-03-23 | 60.00 International Standard under publication |
| 2024-04-12 | 60.60 International Standard published |
| 2025-12-15 | 10.99 Technical Corrigendum 1 |
GQL property graph data model
GQL is a query language specifically for property graphs. A property graph closely resembles a conceptual data model, as expressed in an entity–relationship model or in a UML class diagram. Entities are modelled as nodes, and relationships as edges, in a graph. Property graphs are multigraphs: there can be many edges between the same pair of nodes. GQL graphs can be mixed: they can contain directed edges, where one of the endpoint nodes of an edge is the tail and the other node is the head, but they can also contain undirected edges.Nodes and edges, collectively known as elements, have attributes. Those attributes may be data values, or labels. Values of properties cannot be elements of graphs, nor can they be whole graphs: these restrictions intentionally force a clean separation between the topology of a graph, and the attributes carrying data values in the context of a graph topology. The property graph data model therefore deliberately prevents nesting of graphs, or treating nodes in one graph as edges in another. Each property graph may have a set of labels and a set of properties that are associated with the graph as a whole.
Current graph database products and projects often support a limited version of the model described here. For example, Apache Tinkerpop forces each node and each edge to have a single label; Cypher allows nodes to have zero to many labels, but relationships only have a single label. Neo4j's database supports undocumented graph-wide properties, Tinkerpop has graph values which play the same role, and also supports "metaproperties" or properties on properties. Oracle's PGQL supports zero to many labels on nodes and on edges, whereas SQL/PGQ supports one to many labels for each kind of element. The NGSI-LD information model specified by ETSI is an attempt at formally specifying property graphs, with node and relationship types that may play the role of labels in previously mentioned models and support semantic referencing by inheriting classes defined in shared ontologies.
The GQL project will define a standard data model, which is likely to be the superset of these variants, and at least the first version of GQL is likely to permit vendors to decide on the cardinalities of labels in each implementation, as does SQL/PGQ, and to choose whether to support undirected relationships.
Additional aspects of the ERM or UML models may be captured by GQL schemas or types that describe possible instances of the general data model.
Implementations
The first in-memory graph database that can interpret GQL is available. Aside from the implementation, one can also find a formalization and read the syntax of the specific subset of GQL.Extending existing graph query languages
The GQL project draws on multiple sources or inputs, notably existing industrial languages and a new section of the SQL standard. In preparatory discussions within WG3 surveys of the history and comparative content of some of these inputs were presented. GQL is a declarative language with its own distinct syntax, playing a similar role to SQL in the building of a database application. Other graph query languages have been defined which offer direct procedural features such as branching and looping, and GSQL, making it possible to traverse a graph iteratively to perform a class of graph algorithms, but GQL will not directly incorporate such features. However, GQL is envisaged as a specific case of a more general class of graph languages, which share a graph type system and a calling interface for procedures that process graphs.SQL/PGQ Property Graph Query
Prior work by WG3 and SC32 mirror bodies, particularly in INCITS Data Management, has helped to define a new planned Part 16 of the SQL Standard, which allows a read-only graph query to be called inside a SQL SELECT statement, matching a graph pattern using syntax which is very close to Cypher, PGQL and G-CORE, and returning a table of data values as the result. SQL/PGQ also contains DDL to allow SQL tables to be mapped to a graph view schema object with nodes and edges associated to sets of labels and set of data properties. The GQL project coordinates closely with the SQL/PGQ "project split" of ISO 9075 SQL, and the technical working groups in the U.S. and at the international level have several expert contributors who work on both projects. The GQL project proposal mandates close alignment of SQL/PGQ and GQL, indicating that GQL will in general be a superset of SQL/PGQ.More details about the pattern matching language can be found in the paper "Graph Pattern Matching in GQL and SQL/PGQ"
Cypher
Cypher is a language originally designed by Andrés Taylor and colleagues at Neo4j Inc., and first implemented by that company in 2011. Since 2015 it has been made available as an open source language description with grammar tooling, a JVM front-end that parses Cypher queries, and a Technology Compatibility Kit of over 2000 test scenarios, using Cucumber for implementation language portability. The TCK reflects the language description and an enhancement for temporal datatypes and functions documented in a Cypher Improvement Proposal.Cypher allows creation, reading, updating and deleting of graph elements, and is a language that can therefore be used for analytics engines and transactional databases.
Querying with visual path patterns
Cypher uses compact fixed- and variable-length patterns which combine visual representations of node and relationship topologies, with label existence and property value predicates. By matching such a pattern against graph data elements, a query can extract references to nodes, relationships and paths of interest. Those references are emitted as a "binding table" where column names are bound to a multiset of graph elements. The name of a column becomes the name of a "binding variable", whose value is a specific graph element reference for each row of the table.For example, a pattern will generate a two-column output table. The first column named will contain references to nodes with a label . The second column named will contain references to nodes with a label , denoting the city where the person lives.
The binding variables and can then be dereferenced to obtain access to property values associated with the elements referred to by a variable. The example query might be terminated with a , resulting in a complete query like this:
RETURN p.first_name, p.last_name, c.name, c.state
This would result in a final four-column table listing the names of the residents of the cities stored in the graph.
Pattern-based queries are able to express joins, by combining multiple patterns which use the same binding variable to express a natural join using the clause:
RETURN p.first_name, p.last_name, c.name, c.state
This query would return the residential location only of EU nationals.
An outer join can be expressed by :
RETURN p.first_name, p.last_name, c.name, c.state, ec.name
This query would return the city of residence of each person in the graph with residential information, and, if an EU national, which country they come from.
Queries are therefore able to first project a sub-graph of the graph input into the query, and then extract the data values associated with that subgraph. Data values can also be processed by functions, including aggregation functions, leading to the projection of computed values which render the information held in the projected graph in various ways. Following the lead of G-CORE and Morpheus, GQL aims to project the sub-graphs defined by matching patterns as new graphs to be returned by a query.
From a broad perspective, GQL monitors three key elements during query evaluation and execution:
- the active graph - the property graph currently being used for pattern matching;
- the active table - where computed information up to this point is stored; and
- the active record - which holds the result tuple currently in use.