TigerGraph Supports Graph Query Langauge openCypher
TigerGraph, maker of the graph database of the same name, has announced phased support for openCypher, the open source implementation of the Cypher graph database query language, established by TigerGraph competitor Neo4j. This development could help conform the range of graph database platforms on the market and their query languages, and facilitate the transition to a new, unified language called GQL, which is currently under design.
Yu Xu, CEO and founder of TigerGraph, put it this way: “With openCypher support, we are pushing the bounds of graph innovation and arming developers with another way to adopt and expand their use of graph to find competitive insights in their data.”
The New Stack spoke with TigerGraph COO, Todd Blaschka, and its VP of Product Innovation, Dr. Jay Yu, to discuss the significance of this news. Blaschka and Yu were kind enough to offer a tutorial of sorts, as well, helping us understand the graph query language landscape and some of the syntactical differences between several of the languages. We’ll do our best to reprise that explainer here.
Polyglot or Poly-Glut?
The world of graph databases is a vast web of vendors, platforms and standards. Much like a graph itself, this web contains a number of bilateral relationships, making for affinities, but not uniformity. One facet of that is the various graph database query languages themselves, some of which are supported by multiple platforms, but none of which is supported universally. While the existence of some cross-platform support helps, the overall fragmentation impedes ecosystem progress.
The graph database community wants to fix this. That’s why a graph database standards committee, made up of representatives from several vendors in the space, is working to capture the best of several of the competing query languages and unify them as GQL, a single International Organization for Standardization (ISO) standard graph query language, that is an extension of SQL, and which is on track to be issued as s finalized standard in 2024.
Think you’ve heard of GQL already? Maybe you have, but chances are you’ve come across another language with a similar name. So be careful. Don’t confuse GQL with the Gremlin query language, part of the Apache Tinkerpop project. Don’t confuse it with GSQL, TigerGraph’s own query language, either. And definitely don’t confuse it with GraphQL, which is actually used for querying APIs, rather than graph databases.
Deciphering TigerGraph’s openCypher Support
Again, the goal for GQL is for it to become a fully-blessed standard by 2024. But in advance of that, many graph database companies have rallied around openCypher as an interim standard, and now TigerGraph is jumping on that bandwagon.
TigerGraph’s initial support for OpenCypher will come in the form of a language translator that accepts OpenCypher queries on the input side and generates equivalent GSQL queries on the output side. (Developers can now access a limited preview of the tool to learn how openCypher maps to GSQL). TigerGraph believes this will enable more developers to adopt its platform and will constitute important support for the graph community’s query language consolidation efforts.
Examples, Please
The developer appeal shouldn’t be underestimated, as the syntax of the various graph query languages can differ significantly. For example, a simple GSQL query appears below. Notice its SQL-like syntax, familiar to many developers:
|
1 2 3 4 5 6 |
CREATE QUERY findCustomers() FOR GRAPH G { SELECT DISTINCT c.companyName FROM Customer:c - (BUYS) - Order:o - (HAS_PRODUCT) - Product:p WHERE p.productName = 'Chocolade'; PRINT Result; } |
Seem OK? An openCypher equivalent to the above query would look like the one below (notice the embedded label and property references):
|
1 2 |
MATCH (p:Product {productName:"Chocolade"}) <-[:HAS_PRODUCT]-(:Order)<- [:BUYS] - (c:Customer) RETURN distinct c.companyName |
If those two weren’t different enough, an unrelated query in Gremlin might look like the one that follows. Notice the fluent API-style syntax, with the heavy use of “method chaining” (dot-separated concatenated series of expressions):
|
1 2 |
g.V().has("name","gremlin"). out("knows").out("knows").values("name") |
Standards FTW
The above three examples show the variety of syntax that can be found in graph query languages, and that’s just for the three languages we’ve examined here (there are more). Whether or not you prefer openCypher’s syntax, the fact that it is supported by a number of platforms, now including TigerGraph, makes for progress toward cohesion in the graph database space.
TigerGraph says it will follow up on its translator by bringing openCypher support directly onto its graph database platform, making a standalone translator unnecessary. And, as the industry moves toward a 1.0 release of GQL, TigerGraph will support that as well.
Self-Serving, Pitching in, or Both?
There are a couple of ways of looking at TigerGraph’s announcement. To begin with, it could be a benevolent community effort. But, as TigerGraph uses the translator to demonstrate what it believes is the superior syntax of its own GSQL language, the announcement could also be part of a lobbying effort to marginalize openCypher’s influence in favor of TigerGraph’s own tech.
But since the cohort of graph database vendors is moving towards GQL, and many view openCypher support as the best steppingstone for getting there, it’s more likely that TigerGraph wants to hasten the effort’s momentum, make the graph space less fragmented, more accessible, more productive and, ultimately, more lucrative, for itself and its competitors alike.