Result Table and Visualization

Even though GQL operates on graphs, its results are still logically represented as tables composed of records (rows).

Intermediate Result Table

The intermediate result table is a conceptual model to understand how queries are processed.

Here is the example graph and query:

GQL
MATCH (u:User) WHERE u.age > 30
MATCH (u)->(c:Club)
FILTER c.since > 2010
RETURN u.name, c._id

Statement Intermediate Result Table

MATCH (u:User)
WHERE u.age > 30

The intermediate table contains one column (variable) u with three records (rows).

`u`
(:User {_id: "U1", name: "mochaeach", age: 31})
(:User {_id: "U2", name: "purplechalk", age: 45})
(:User {_id: "U3", name: "Brainy", age: 36})

MATCH (u)->(c:Club)

The statement evaluates u row by row and adds a new column c to the intermediate result table:

If a record of u yields no result, that record is discarded.
If it yields a single result, that value is added to column c.
If it yields multiple results, the record of v is duplicated for each result, and each corresponding c record is added.

`u`	`c`
(:User {_id: "U1", name: "mochaeach", age: 31})	(:Club {_id: "C1", since: 2002})
(:User {_id: "U2", name: "purplechalk", age: 31})	(:Club {_id: "C1", since: 2002})
(:User {_id: "U2", name: "purplechalk", age: 31}	(:Club {_id: "C3", since: 2011})

FILTER c.since > 2010

The statement evaluates c row by row and discards records that don't meet the filtering condition.

`u`	`c`
(:User {_id: "U2", name: "purplechalk", age: 31}	(:Club {_id: "C3", since: 2011})

Statement Output Table

RETURN u.name, c._id

The RETURN statement defines the output table.

`u.name`	`c._id`
purplechalk	C3

This example is a linear query, where statements are executed sequentially. In composite queries, each linear query is executed independently and produces its own output table. These output tables are then combined using the specified conjunction method.

Order of Rows

Without an explicit use of ORDER BY, Ultipa is free to return the result rows in any order — and that order may:

Vary between query runs
Change after database updates
Differ across Ultipa versions

Cartesian Product in Queries

A Cartesian product occurs in GQL when query parts have no shared variables or explicit connections between them. In such cases, all combinations of the result rows from each part are returned.

Consider the example:

GQL
MATCH (u:User)
MATCH (c:Club)
RETURN u.name, c._id

There are 4 User nodes and 3 Club nodes. Since there’s no relationship between u and c, the query produces a Cartesian product, yielding 4*3 = 12 records:

`u.name`	`c._id`
Jody	C1
purplechalk	C1
mochaeach	C1
Brainy	C1
Jody	C3
purplechalk	C3
mochaeach	C3
Brainy	C3
Jody	C2
purplechalk	C2
mochaeach	C2
Brainy	C2

While this is a small example, in a real-world graph with large datasets, Cartesian products can lead to huge result sets, consuming significant memory and degrading performance. Therefore, avoid Cartesian products unless they are explicitly intended.

Result Visualization

While GQL results can be returned in tabular format, one of the defining features of graph databases is the ability to visualize results as graph structures, making it easier for users to see and explore the relationships within their data.

When running GQL queries in Ultipa products such as Ultipa Manager and GQL Playground, query results of nodes and paths can be rendered in graph view, offering an intuitive and interactive way to navigate the result graph.

Result Visualization in Ultipa Manager