Open or closed? On graph database access, query languages, community building, and TigerGraph
Having an entry path, as well as a strong community, is important for any solution, and graph databases are no different. Following latest developments in graph query languages, TigerGraph is changing its strategy. How will this affect the domain?
If you’ve been watching the graph database space, you probably know TigerGraph. It’s one of the latest entries, coming out of stealth in September 2017. TigerGraph has managed to get attention in a number of ways: its massively parallel architecture, the benchmarks it has released, the names of its clients, and its strong presence in industry events.
Being the new kid on any block however is not easy, and graph databases are no different. Going against incumbents is hard in and by itself. The fact that people who would be interested in trying out TigerGraph had no easy way to do this only made it harder. Just think about it:
Most of the competitors in the graph database space are either open source, or are based on standards, or have a huge footprint, or at least have a free edition people can play with in order to acquaint themselves with the platform. TigerGraph had none of those ways to reach out, and there’s no doubt that puts off many prospects. But that has just changed.
On June the 12th, TigerGraph officially announces a free Developer Edition of its graph analytics platform for lifetime non-commercial use. Yu Xu, founder and CEO of TigerGraph, says:
“We developed TigerGraph based on years of research and conversations with our customers to address their most pressing needs – a scalable, high performance platform for big data graphs.
One hour with our free Developer Edition is all you need to experience TigerGraph’s superiority in unlocking value from connected data at massive scale.”
Whether that holds, you can judge for yourself. The important thing however is that now people interested in taking TigerGraph for a spin can actually do this and judge for themselves. This seems like an obvious, and long time coming, move for TigerGraph, so let’s see what that will do for its adoption. But, that’s not all.
On Graph Query Languages
“As graphs continue to go mainstream, the next phase of the graph evolution has arrived. Cypher vs. Gremlin is no longer the right question to ask. The time has come to rethink graph analytics with TigerGraph and GSQL, the most complete query language on the market”, says Xu in the same press release.
We have already explained the importance of query language for the fast-moving graph database landscape. In the relational database world, SQL is a standard everyone coalesces around. SQL is so widespread that its adoption goes beyond relational databases, and we’ve seen SQL ports over anything from NoSQL databases to S3 storage.
In the graph database world, there’s no such thing as a universally accepted query language, same as there was no such thing in the early days of relational databases by the way. The main reasons are that graph databases are relatively new, and there are different and competing models, philosophies and vendors.
In graph databases, we have RDF and the property graph model. In the RDF world, there is W3C standard query language, SPARQL, and despite some differentiations there is vendor and user consensus on its use. But things are different in the property graph world.
There is no standard as such, and each vendor has its own way of approaching the query language issue. The two efforts that come closer to being a standard are OpenCypher and Gremlin. OpenCypher is the open source offspring of Cypher, Neo4j’s query language. Gremlin is a language for graph traversals that works with the Apache Tinkerpop framework.
Recently, Neo4j came forward with a proposal to unify Cypher with two more property graph query languages, PGQLand G-Core, which was, expectedly, met with mixed reactions.
A conversation I’m tired of…
X: We need a standard graph querying language.
Y: We have one from the W3C: SPARQL.
X: That’s not a property graph query language.
Y: Why didn’t you say “property graph query language” in the first place?
X: We need a standard graph query language.— Bob DuCharme (@bobdc) May 26, 2018
A standard query language sounds good in theory. Those languages seem like they have a lot in common. And according to the poll that came with the proposal, 96% of respondents find this a good idea.
However, it’s worth questioning what the real impact of unifying Cypher with a language created in a research lab, and another one only used by one vendor, will be in practice. We’ll have to wait and see whether the proposal actually moves to implementation to answer that question.
Opening up
This, however, has brought attention to the issue of graph query languages. As a consequence, TigerGraph has come forward as well, in an effort to communicate what it sees as the benefits of its own query language, GSQL. If a number of posts by TigerGraph’s executives did not make it clear enough already, the explicit reference above by its CEO should.
TigerGraph faces a similar predicament with query language as it did up to now with platform access. Its GSQL language remains specific to TigerGraph and TigerGraph alone. Whatever advantages it may have, those will remain reserved for TigerGraph users. Offering access to its platform may help adoption, but it will not change this fact.
Open, or closed?
When discussing query languages with Neo4j’s CEO a while back, it was interesting to hear him say Neo4j should have opened up Cypher long before it actually did. And that makes sense, according to the open source way of thinking: if you think your platform, or in that case your query language, is so great, opening it means others get a chance to evaluate, contribute, or maybe adopt it.
Neo4j, and many other vendors, realize the importance of having a strong community around their offering. A community brings strength to a solution in many ways – from advocacy to support, and from guiding product development to contributing features. So TigerGraph is also trying to reach out there, taking its first baby steps. Of course, building a community takes much-much more than starting a forum, and it will take consistent effort and dedication to do this.
What is probably still the most interesting question however is how vendors strategy in terms of query language will evolve. Will we see more query languages following down the open source path? Again, we’ll have to wait and see. But that would probably be a good thing both for them and for users.
Would you like to receive the latest news on graph databases in your inbox? Easy – just signup for Year of the Graph Newsletter below. Have some news you think should be featured in an upcoming newsletter? Easy too – drop me a line here.
Disclaimer: TigerGraph is sponsoring the Connected Data London 2018 event which i am co-organizing, and gave me early access to the press release about its Developer Edition.
