It seems like the time is right to create one standard property graph query language. Fusing the best of Cypher, PGQL and G-CORE into a more comprehensive query language built specifically for graph solutions.
Should the property graph community unite to create a standard graph query language, GQL, alongside SQL? Vote now or read on and vote afterwards.
Translations: Spanish, Russian
Property graph data has a big presence
Amazon Neptune, Oracle PGX, Neo4j Server, SAP HANA Graph, AgensGraph (over PostgreSQL), Azure CosmosDB, Redis Graph, SQL Server 2017 Graph, Cypher for Apache Spark, Cypher for Gremlin, SQL Property Graph Querying, TigerGraph, Memgraph, JanusGraph, DSE Graph … it’s hard to keep up.
And an even bigger future
Thousands of applications already use the rich, intuitive graph data model. The ability to express, find and extract complex relationships and patterns; to execute graph algorithms; to register transactions; and to perform graph analysis is proving its value every day, in every domain of business and science. And adoption is accelerating.
Relational data has SQL
SQL is one of the key underpinnings of modern information technology. We need a declarative query language for the powerful – and distinct – property graph data model, to play a similar role.
Many graph databases and services are not features of relational systems, but native, optimized implementations. And many graph queries, when implemented over relational systems, do not need to be tied to tables on the surface. There is a big role for graph extensions to SQL, but they are unlikely to be the leading edge of graph querying.
Property graph data needs GQL
Like SQL, the new GQL (Graph Query Language) needs to be an industry standard.
Different languages for different products help no one. An international standard will let the whole graph data market grow, to the mutual benefit of all vendors and all users. One language, one skill set. A common query language focuses support around data modelling, ETL and visualization tools for graph data, and portable queries mitigate vendor lock-in.
But GQL also needs to be tuned and agile to meet the needs of the expanding property graph data industry. It should work with SQL, but it should not be confined by SQL. GQL would be a language that complements the traversal API of Apache Tinkerpop’s Gremlin as well as SPARQL for RDF triple-stores. This results in better choices for developers, data engineers, data scientists, CIOs and CDOs alike.
Three languages
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 Linked Data Benchmark Council (co-authored by world-class researchers from the Netherlands, Germany, Chile, the U.S, and technical staff from SAP, Oracle, Capsenta and Neo4j).
You’d be hard pressed to tell them apart for many common graph queries. They have very similar data models, syntax and semantics. Each one is ahead of the game or behind the game in one way or another.
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, where regular expressions find and retrieve patterns even more concisely and flexibly.
Three into one should go
My name is Alastair Green. I help to organize work on graph query language standards and research at Neo4j, Inc., working with talented engineers, language architects and standards specialists within our company and among collaborators in industry and academia.
Sponsored by our CEO, Emil Eifrem, and our VP of Products, Philip Rathle, the Neo4j team is advocating that the database industry and our users get away from two or three blurred photocopies of the same ideas, and get together 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 graphs.
One property graph query language, one GQL
We’ll be working with anyone who wants to help create GQL as a new open industry standard. We’d love it to be an ISO standard alongside SQL. Or perhaps it will end up in another venue.
But that’s not the most important thing. A technically strong standard, with strong backing among vendors and users: that’s what matters most. So we’ll be appealing for your public, vocal support. If there is a will, there will be a way.
Open letter to the database industry