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
About the Author
Emil Eifrem, Philip Rathle & Alastair Green , Neo4j
Emil Eifrem sketched what today is known as the property graph model on a flight to Mumbai in 2000. As the CEO and Co-Founder of Neo4j and a co-author of the O’Reilly book Graph Databases, he’s devoted his professional life to building and evangelizing graph databases.
Philip Rathle has a passion for building great products that help users solve tomorrow’s challenges. He spent the first decade of his career building information solutions for some of the world’s largest companies: first with Accenture, then with Tanning Technology, one of the world’s top database consultancies of the time, as a solution architect focusing on data warehousing and BI strategy.
Alastair Green brings a strong mix of consulting, architecture, and product skills to the Neo4j team. He is Neo4j’s product manager for the Cypher language, and member of the Neo4j Cypher Language Group (CLG)