GQL Is Now a Global Standards Project alongside SQL

The votes are in.

This past June, national standards bodies around the world – belonging to ISO/IEC’s Joint Technical Committee 1 (responsible for IT standards) – began voting on the GQL project proposal.

Graph Query Language (GQL) is a new language being developed and maintained by the same international working group that also maintains the SQL standard.

Now, it’s official: Earlier this week, the ballot closed and the proposal passed, with seven countries putting experts forward to work on the four-year standard query language project.

GQL draws heavily from existing languages, but the main inspiration has so far been Cypher (now with over 10 implementations, including six commercial products), Oracle’s PGQL and SQL itself. The GQL project is the first ISO/IEC international standard database languages project since SQL.


Ten countries voted for the new project: China, Korea, Sweden, the U.S., Germany, the UK, the Netherlands, Denmark, Kazakhstan, Canada and Finland. Five abstained on grounds of lack of expertise to judge or comment on the proposal.

Only Japan voted against, putting forth two arguments; existing languages out there already do the job, and specifically that SQL/Property Graph Query extensions in conjunction with the rest of the SQL standard can cover the ground.

It should be noted: Many of the companies and national standards bodies that are backing the GQL initiative do not see GQL and SQL as competitors but rather complement each other through shared foundations and interoperation.

Why We Need a Graph-Specific Query Language

Many vendors, researchers and users agree that graph databases can be developed using non-relational storage and runtime models – a.k.a. native graph technology. Examples include Neo4j’s industry-leading graph database platform and the new Redis Labs graph product.

However, they most definitely want a language – like Cypher – that covers insertion and maintenance of data, and not just data querying. And SQL is unlikely to be the right model for a graph-centric language that can “compose over graphs” (i.e. takes graphs as query inputs and spits out a graph as a result, the same way SQL can read tables and form result sets which are new tables).

GQL will build on work in openCypher Morpheus, which brings Cypher to Apache Spark, and the inspiration of G-CORE from the Linked Data Benchmark Council (LDBC), to give users a composable graph query language, enabling all of those features.

Combining all three of these streams will make GQL into the conceptual equal of SQL … and then some.

Read my post on LinkedIn for a more in-depth perspective on why the advocates of GQL were right to propose a new standard language alongside SQL.

The Next Step: WG3 meeting soon in Arusha, Tanzania

The work of the GQL project starts in earnest at the next meeting of the SQL/GQL standards committee, ISO/IEC JTC 1 SC 32/WG3, in Arusha, Tanzania, later this month.

It is impossible at this stage to say when the first implementable version of GQL will become available, but it is highly likely that some reasonably complete draft will have been created by the second half of 2020.

GQL Community Update 9 October

On Wednesday 9 October, a GQL Community Update web-conference is being held, co-chaired by Peter Boncz, chair of the LDBC, and Keith Hare, convenor of WG3.

This meeting will discuss different topics and workstreams, including community efforts organized in two LDBC “task forces” for property graph schema and existing languages analysis. This follows the decision by LDBC’s board of directors to act as the organizing centre for community efforts to support GQL, taking advantage of LDBC’s formal liaison with WG3.

Ideas are brewing about using formal denotational semantics to assist the quality and exactness of the GQL specification, building on similar work in Edinburgh and Warsaw to define formal semantics for parts of Cypher (including the interesting Cypher.PL executable semantics project, written in Prolog). It is also highly likely as time progresses that open source software for grammar tooling and for conformance testing will begin to be created to support the official specification, in the style of the openCypher project.