TuGraph-DB Query Engine Overview: Graph Query Language Evolution, Engine Features, and Architectural Roadmap

Introduction – The presentation introduces the TuGraph‑DB database query engine and outlines three main sections: an overview of graph query languages, a description of the TuGraph 4.0 query engine, and the architecture and evolution plan.

1. Graph Query Language Introduction – The evolution of graph query languages is divided into three stages: the early graph database era (2000s) with no dedicated language, the emergence of languages such as Gremlin and Cypher (2011‑2015) leading to openCypher, and the current iteration stage where GQL becomes an international standard (starting 2019) with TuGraph gradually implementing it.

The languages are categorized as declarative (e.g., Cypher, PGQL, G‑CORE) and imperative (e.g., GSQL, Gremlin). Declarative languages resemble SQL and focus on the *what* of a query, relying on optimizers, while imperative languages resemble procedural code (like Python) and give users more control at the cost of higher learning complexity.

GQL, the emerging standard, draws heavily from openCypher and aims to unify graph query languages, with Ant Group’s TuGraph and GeaFlow already supporting it.

2. Query Engine Introduction – TuGraph 4.0 implements GQL support for basic SNB and FINBENCH short queries. Future plans include expanding GQL coverage (e.g., DDL), integrating a new GEAX optimization engine, enhancing the test suite, and enabling benchmark‑driven development.

Benchmarking (SNB, FINBENCH) is discussed as one evaluation dimension among performance, expressiveness, robustness, and optimization capabilities.

3. Architecture and Evolution Plan – The current architecture parses queries into an AST, validates them, creates a logical plan via a planner, applies optimizations based on schema/statistics, and executes the plan. Two main challenges are supporting multiple query languages (Cypher and GQL) and integrating diverse storage engines beyond the single‑node version.

The design draws inspiration from Apache Calcite, providing parsing, validation, and optimization services. The upcoming version will add a GEAX front‑end layer that abstracts graph syntax (GST), supports plug‑in logical operators and optimizers, and separates query language processing from execution.

GEAX will act as a modular query‑processing framework, enabling easy integration of GQL into other graph systems (e.g., GraphScope) and fostering a unified declarative graph query language ecosystem.

In the next 3‑6 months, the team plans to release the GEAX front‑end, provide a playground for users to view logical execution plans, and continue iterative improvements toward a more extensible, multi‑language, multi‑engine query platform.

Finally, the presenter thanks the audience for their attention.