A new direction for TigerGraph?

Written By:
Content Copyright © 2023 Bloor. All Rights Reserved.
Also posted on: Bloor blogs

A new direction for TigerGraph? banner

TigerGraph is one of the larger and more well-known vendors in the graph space, and it has long sold itself on two major points: 1) the essential usefulness of graph technology, and 2) its ability to deliver graph at high speed and scale, the necessity of which is driven by the interconnectedness of graph and the combinatorial complexity which it leads to. While the latter point is still very much part of TigerGraph’s marketing strategy, the former has faded from view in favour of more specific value propositions.

One of the more notable of these propositions concerns AI and machine learning (ML). As one of the more recent hot topics in the data space, this should hardly be surprising, though it is no less useful for it. For instance, graphs in general, and TigerGraph in particular, can use graph analytics to accelerate the maturation of neural networks and other AI models by seeding them with knowledge of important relationships (and, conversely, unimportant relationships) derived from graphs. In this way, TigerGraph has positioned itself as a platform for enabling AI and ML.

To facilitate this, TigerGraph has continued to build out its library of open-source graph algorithms, and it has also created a specialised workbench for machine learning – useful for, say, building out neural networks backed by graph tech. The platform’s connector layer also allows various established ML technologies (such as PyTorch and Jupyter Notebook) to act as if they had a graph (and more specifically, a TigerGraph) backend. Other, less AI-driven developments include increased support for OpenCypher – useful when TigerGraph’s bespoke GSQL is overkill, which in all honesty might be most of the time – and the creation of TigerGraph Insights, a Tableau-esque analytics tool native to the platform.

As for TigerGraph’s historically very competitive performance, in keeping with the company’s new marketing philosophy the emphasis is not on performance for performance’s sake, but rather because faster query speeds mean more graph traversals and thus deeper and more accurate querying. This effect can be really quite substantial, especially if it allows graph queries to continue to the point that they generate a meaningful result when they otherwise would not. Actually, the latter can be quite an insidious effect, as graph analytics queries do not naturally converge on their final results in the same way that other analytics queries do. *

Interestingly, TigerGraph’s attitude to supernodes – nodes containing an overabundance of edges, which I touched on in another recent article on graph – is that they are a design issue, rather than a performance one: you should build your graphs such that they don’t exist, rather than waste resources trying to meaningfully analyse them. On the one hand, this attitude seems very valid – supernodes may well be the result of poor graph design. On the other, graphs containing supernodes already exist and most likely will always exist. Providing additional options to deal with would be useful.

All that said, the title of this blog asked whether TigerGraph is taking a new direction. In the grand tradition of Betteridge’s law of headlines**: no. Not really, anyway. Frankly, that’s a good thing – TigerGraph’s offering has always been formidable, and it would be a shame for it to go the way of the dodo. What’s really new is its marketing direction, and in particular its appetite for AI. On that front, I heartily approve.


*Because I have a mathematics degree and want to use it, I’ll explain a little further: the law of large numbers, which among other things guarantees that you can take a sample of your data, analyse it, then meaningfully generalise the result, does not apply to graph spaces and analytics. As such, while non-graph queries gradually approach their ultimate result, and thus if they’re stopped when they’ve only analysed 80% of your data you can still be fairly confident in whatever they turn up, it’s functionally impossible to tell how accurate the result of a graph analytics query is until the query has finished in its entirety. As you might imagine, this makes fast query times especially important for graph analytics.

**Any headline that ends in a question mark can be answered by the word no.

Post a public comment?