A graph database designed for deep analytics
graph databases offer a more efficient way to model relationships and networks than relational (SQL) databases or other kinds of NoSQL databases (document, wide column, and so on). Lately many products have arisen in this space, which was originally (in 1999) the sole province of Neo4j.
TigerGraph, a recent arrival, is a “real-time native parallel graph database.” TigerGraph is available for deployment in the cloud or on-premises, it scales both up and out, it automatically partitions a graph within a cluster, it's ACID compliant, it has built-in data compression, and it claims to be faster than the competition. As we'll see, it uses a message-passing architecture that is inherently parallel in a way that scales with the size of the data.
TigerGraph was designed to be able to perform deep link analytics as well as real-time online transaction processing (OLTP) and high-volume data loading. By “deep link analytics,” TigerGraph means following relationships from a vertex through the graph for three or more hops and analyzing the results. Most other graph databases were designed primarily for OLTP and for the navigation and analysis of small numbers of hops; any serious analytic capabilities were added later.
While there are several open-source graph query languages that have been widely adopted, such as Cypher, Gremlin, and SPARQL, TigerGraph has a new query language, GSQL. GSQL combines SQL-like query syntax with Cypher-like graph navigation, plus procedural programming and user-defined functions.