TigerGraph today updated its graph database to make it possible to scale compute and storage resources independently of each other.
In addition, the TigerGraph Savanna release can now be deployed in any cloud computing environment in addition to the software-as-a-service (SaaS) edition of the platform.
TigerGraph now also supports three different programming languages: GSQL, OpenCypher and GQL, the ISO standard graph query language that TigerGraph helped develop.
Finally, the company is adding support for additional data sources such as the Snowflake cloud service, dedicated compute workspaces tailored for transaction processing and analytics workloads, and nine additional pre-configured solution kits for building applications that address, for example, transaction fraud or supply chain management.
TigerGraph CEO Rajeev Shrivastava said the company is taking advantage of cloud-native infrastructure technologies to make it simpler to scale workloads in parallel. That approach can reduce the total cost of deploying its graph database by as much as 25%, while making it possible to provision compute resources six times faster than rival graph databases, the company claimed.
In general, graph databases are gaining traction across a wide range of use cases, running from knowledge graphs to network management systems. The overall goal is to make it simpler for organizations to create and visualize relationships across a diverse range of data sets.
Additionally, many organizations are also employing graph databases to establish the relationship between various data sets before exposing them to a large language model (LLM). That approach helps ensure the output generated by an LLM is more accurate, noted Shrivastava. In some cases, organizations are also discovering that an application built on top of a graph database is better suited for some classes of applications altogether, he added.
Of course, there are many proponents of databases that have been extended to include the ability to process graph data. That approach eliminates the need to deploy and manage a separate graph database. However, a standalone graph database is typically going to be able to process data at a higher level of scale in a production environment.
Regardless of approach, graph database technologies are being more widely employed across the enterprise. The challenge many organizations are encountering is finding application developers that have the skills required to build applications using these databases. One of the primary reasons GQL is gaining traction is that it promises to eliminate the need to master a different programming language for graph database applications that might be built using different database platforms.
Each IT organization will need to decide for itself to what degree to rely on a dedicated graph database platform. The one thing that is certain is that organizations increasingly appreciate the value of the data, and they will need to find more efficient ways to operationalize it.
Arguably, that will require being able to more easily establish the relationships with all the various data sets that exist within an organization. Otherwise, far too many organizations will find themselves collecting and storing massive amounts of data in ways that don’t always yield as much value to the business as everyone might have hoped.
