For years now, I’ve been watching the excruciatingly slow process of ISO language standard development as a number of academicians, national standards bodies, scientists and DBMS firms inched their way towards the creation of a standard query language for graph DBMS. To put this in perspective, the ISO has created exactly one DBMS language standard since 1987. Most likely you have heard of it: SQL.
And now, there is a second: GQL, announced as an ISO standard April 12 at the end of a 4 year process. As the eminent Thomas Frisendal noted in a LinkedIn post: “I simply think this is the most important disruption of the database market, ever!” I dislike hyperbole, but it is hard not to agree. Not since the adoption of SQL itself has such an important standard appeared.
Graph DBMS has become more and more successful commercially as the value of preserving relationships along with data became obvious, and it’s more relevant than ever in the era of generative AI. But marketplace success has been hampered by a plethora of approaches and languages, although some leaders emerged over the years. I was following over 4 dozen of them when I covered DBMS at Gartner. Nonetheless, a few emerged to some degree of commercial success. Most notably, Neo4j almost broke into the top 20 DBMS by revenue in 2023, as I noted in my recent post on the market. AWS Neptune has been getting a lot of activity, and numerous DBMS vendors have added graph capabilities into their products in an attempt to capture some of the interest.
Much of GQL’s core derives from Neo4j’s Cypher language (the link to Wikipedia also has some useful narrative about the evolution of the space), and the canny decision to foster an open source community with openCypher. It was doing well already as a de facto standard, competing with SPARQL, Gremlin and numerous one-offs within specific products, both commercial and open source. The number of other vendors who participated in the standards effort spoke volumes: they included ArangoDB, DataStax, Google, Oracle, Redis, TigerGraph (I’m surely leaving some out – please leave me a comment and I’ll add you.) And of course, high tech user companies have contributed as well – I’ve seen Uber contributions referred to frequently.
Neo4j’s products will clearly benefit from this outcome – their engineering team has ensured that their own product implemented elements of the standard as it evolved, side by side with other vendor teams. Adoption of, and moving to, the standard will thus be a smooth path for their existing customers. More important, the presence of a standard means new adopters will have one less variable to wrestle with. Philip Rathle has written a very helpful blog post that sums things up. And standards are inclusive, not exclusionary, by nature. If you’re not on board yet, the direction is much clearer now. It’s time.