Result Table and Visualization

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

Intermediate Result Table

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

Example graph:

GQL
INSERT (mochaeach:User {_id: 'U1', name: 'mochaeach', age: 31}),
       (purplechalk:User {_id: 'U2', name: 'purplechalk', age: 45}),
       (brainy:User {_id: 'U3', name: 'Brainy', age: 36}),
       (jody:User {_id: 'U4', name: 'Jody', age: 29}),
       (c1:Club {_id: 'C1', since: 2002}),
       (c2:Club {_id: 'C2', since: 2020}),
       (c3:Club {_id: 'C3', since: 2011}),
       (purplechalk)-[:Follows]->(mochaeach),
       (purplechalk)-[:Follows]->(brainy),
       (jody)-[:Follows]->(brainy),
       (mochaeach)-[:Joins]->(c1),
       (purplechalk)-[:Joins]->(c1),
       (purplechalk)-[:Joins]->(c3),
       (jody)-[:Joins]->(c2)

Example query:

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

{
  "id": "U1",
  "labels": ["User"],
  "properties": {"name": "mochaeach", "age": 31}
}

{
  "id": "U2",
  "labels": ["User"],
  "properties": {"name": "purplechalk", "age": 45}
}

{
  "id": "U3",
  "labels": ["User"],
  "properties": {"name": "Brainy", "age": 36}
}

{
  "id": "U1",
  "labels": ["User"],
  "properties": {"name": "mochaeach", "age": 31}
}

{
  "id": "C1",
  "labels": ["Club"],
  "properties": {"since": 2002}
}

{
  "id": "U2",
  "labels": ["User"],
  "properties": {"name": "purplechalk", "age": 45}
}

{
  "id": "C1",
  "labels": ["Club"],
  "properties": {"since": 2002}
}

{
  "id": "U2",
  "labels": ["User"],
  "properties": {"name": "purplechalk", "age": 45}
}

{
  "id": "C3",
  "labels": ["Club"],
  "properties": {"since": 2011}
}

{
  "id": "U2",
  "labels": ["User"],
  "properties": {"name": "purplechalk", "age": 45}
}

{
  "id": "C3",
  "labels": ["Club"],
  "properties": {"since": 2011}
}

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:

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