It’s Time for a Single Property Graph Query Language [Vote Now]


The time has come to create a single, unified property graph query language.

Different languages for different products help no one. We’ve heard from the graph community that a common query language would be powerful: more developers with transferable expertise; portable queries; solutions that leverage multiple graph options; and less vendor lock-in.

One language, one skill set.

The Property Graph Space Has Grown…a Lot


Property graph technology has a big presence, from Neo4j and SAP HANA to Oracle PGX and Amazon Neptune. An international standard would accelerate the entire graph solution market, to the mutual benefit of all vendors and – more importantly – to all users.

That’s why we are proposing a unified graph query language, GQL (Graph Query Language), that fuses the best of three property graph languages.

Relational Data Has SQL, Property Graphs Need GQL


Although SQL has been fundamental for relational data, we need a declarative query language for the powerful – and distinct – property graph data model to play a similar role.

Like SQL, the new GQL needs to be an industry standard. It should work with SQL but not be confined by SQL. The result would be better choices for developers, data engineers, data scientists, CIOs and CDOs alike.

Right now there are three property graph query languages that are closely related. We have Cypher (from Neo4j and the openCypher community). We have PGQL (from Oracle). And we have G-CORE, a research language proposal from the Linked Data Benchmark Council [LDBC] (co-authored by world-class researchers from the Netherlands, Germany, Chile, the U.S, and technical staff from SAP, Oracle, Capsenta and Neo4j).

The proposed GQL (Graph Query Language) would combine the strengths of Cypher, PGQL & G-CORE into one vendor-neutral and standardized query language for graph solutions, much like SQL is for RDBMS.

Each of these three query languages have similar data models, syntax and semantics. Each has its merits and gaps. Yet, their authors share many ambitions for the next generation of graph querying, such as a composable graph query language with graph construction, views and named graphs; and a pattern-matching facility that extends to regular path queries.

Let Your Voice Be Heard on GQL


The Neo4j team is advocating that the database industry and our users collaborate to define and standardize one language.

Bringing PGQL, G-CORE and Cypher together, we have a running start. Two of them are industrial languages with thousands of users, and combined with the enhancements of a research language, they all share a common heritage of ASCII art patterns to match, merge and create graph models.

What matters most right now is a technically strong standard, with strong backing among vendors and users. So we’re appealing for your vocal support.

Please vote now on whether we should unite to create a standard Graph Query Language (GQL), in the same manner as SQL.



For more information, you can read the GQL manifesto here and watch for ongoing updates.


Emil Eifrem, CEO;
Philip Rathle, VP of Products;
Alastair Green, Lead, Query Languages Standards & Research;
for the entire Neo4j team