MultiGraph Overview

One TigerGraph instance can manage multiple graphs, each with its own set of user privileges:

  • Users with WRITE_SCHEMA privilege on the global scope can create multiple graphs on one TigerGraph instance.

  • Users with WRITE_SCHEMA privilege can include a global vertex or edge type in one or more graphs. Global types can be shared among multiple graphs.

  • Users with the admin or designer role for a particular graph can add local vertex types and edge types to their own graph. Local types cannot be shared among multiple graphs.

The following image illustrates an example use case of the MultiGraph feature:

Diagram of the MultiGraph architecture in the shape of a three-section Venn diagram divided between the Product Department, Customer Department, and IT department. Each area of the diagram has connected data points that correspond to different parts of the main graph database.

Graphs

A graph is defined as all the vertices and edges of a set of vertex types and edge types. Access to each graph is managed independently. However, if two graphs share a global type, the data in the shared type are shared between graphs. Each graph contains its own data loading jobs and queries, which do not affect and are not visible to other graphs.

Graph-specific roles and privileges

The TigerGraph system includes several predefined roles. Each role is a fixed and logical set of privileges to perform operations. In order to access a graph, a user must be granted a role on that graph. Without a role, a user has no meaningful access.

For details about managing users, privileges, and roles, see User Access Management.

Setting a working graph

A user must set their working graph in order to access that graph, either using the -g flag with the GSQL command, or by using the USE GRAPH command. Users who have privileges on more than one graph may only work with one graph at a time.

Note that the CREATE commands for queries, loading jobs, and schema change jobs require that the graph name be specified, even for systems with only one graph.

Use cases

MultiGraph enables several powerful use cases:

  • Multiple Tenancy: Use one TigerGraph instance to support several completely separate data sets, each with its own set of users. Each user community cannot see the other user communities or other data sets.

  • Fine-grained privileges on the same set of data: Role-based access control, available on single graphs, grants permission for the privilege to run queries (include data modification queries).

  • Overlapping graphs: Graphs can partially overlap to enable a combination of shared and private data.

  • Hierarchical subgraphs: A graph (Graph X) can be defined to cover the domains of Graphs Y and Z, that is, Graph X = (Graph Y) U (Graph Z). This provides an interesting way to describe a data partitioning or parent-child structure. (This is not the same as defining subclasses of data types; data types are still independent.)

Effect on other specifications

  • RESTPP Endpoints: Endpoints that pertain to the graph data must include the name of the graph in the request URL. See RESTPP API User Guide.

  • User Authentication secrets and tokens: Our commands and procedures follow OAuth standards. See User Access Management.