AvantGraph: Unified Graph Query Engine
- AvantGraph is a graph-query engine that unifies graph analytics and database processing using a linear-algebraic programming model.
- It implements GraphAlg, a domain-specific language that expresses advanced graph algorithms via core linear-algebra primitives.
- The system leverages optimizations like sparsity analysis, loop-invariant code motion, and in-place aggregation to achieve competitive performance benchmarks.
AvantGraph is a graph-query engine designed to unify graph analytics and database query processing through a shared logical and physical pipeline centered on a linear-algebraic programming model. AvantGraph implements GraphAlg, a domain-specific language for expressing advanced graph algorithms using matrix representations and operations, compiling these into optimized relational algebra plans for execution. It achieves significant reductions in code complexity and delivers performance competitive with or surpassing current graph database and RDBMS-based analytics solutions on LDBC Graphalytics benchmarks (Graaf et al., 10 Jan 2026).
1. System Architecture
AvantGraph presents a uniform query engine for both Cypher graph queries and GraphAlg programs, utilizing a single Internal Plan Representation (IPR) to harmonize its query and algorithm processing. The Cypher parser is extended with the WITH ALGORITHM block, enabling the direct inclusion of GraphAlg scripts inside standard graph queries. The processing pipeline includes:
- The planner dispatches the GraphAlg Abstract Syntax Tree (AST) to the GraphAlg compiler upon encountering a WITH ALGORITHM block.
- The compiler executes a four-stage workflow:
- Desugaring: Full GraphAlg syntax is reduced to a small Core language rooted in MATLANG and for-MATLANG primitives.
- Static Analysis: Type checking, dimension consistency, and sparsity analysis are performed.
- Optimization: Core-level optimizations including semiring-based fusion are applied.
- Translation: Core operators are mapped to extended relational algebraic constructs—specifically joins, aggregates, and the Loop node—producing final IPR.
Logical optimization (join reordering, predicate pushdown) is applied agnostically across query and algorithm boundaries. Two specialized loop optimizations are integrated at the planning level: loop-invariant code motion and in-place aggregation. The physical plan execution leverages hash build/probe operations and pipelined aggregations with loop support.
2. Programming Model and Core Operators
GraphAlg exposes a concise set of linear-algebra primitives operating over semirings for matrices and vectors. The essential operators are:
Matrix–Vector Multiply: , computed as for , .
Elementwise Apply: yields for and .
Diagonalize a Vector: , with , for for .
Reduction Operators:
- Row sum:
- Column sum:
- Total sum:
- One-vector: , all entries are .
- pickAny: Selects one nonzero entry per row in .
- Bounded Loop: for executing loop bodies with matrix state variables over iterations.
All GraphAlg Core operators map directly to extensions of relational operators and a single Loop construct, ensuring seamless query/algorithm integration.
3. Static and Runtime Optimizations
AvantGraph’s optimizer implements several domain-specialized strategies:
- Sparsity Analysis: Matrices and vectors are internally stored as relations of triples in a sparse (CSR-like) format. The compiler tracks which operations maintain sparsity (e.g., matmul, elementwise operations) and only materializes dense representations when strictly needed, avoiding quadratic blow-up for large sparse graphs.
- Loop-Invariant Code Motion: Subplans building hash tables that do not depend on loop-carry state are hoisted outside of loops, enabling single hash builds for repeated loop probes and minimizing pipelined materialization.
- In-Place Aggregation: For algorithms incrementally updating aggregates (e.g., SSSP, WCC), the planner rewrites loop bodies where the top operator is a grouped aggregation so that updates are applied directly to existing hash tables, enabling efficient fixpoint detection and early loop exit.
4. Implementation Specifics
AvantGraph’s execution back-end relies on several core strategies:
- Loop Operator: Physical Loop node accepts initial state tables and an iteration bound; the loop body consists of subplans for all carried state variables, and the result (conventionally the first state) is produced at completion.
- Storage Model: Matrix and vector data are stored sparsely—only nonzeros—as (row, col, value) triples, both on disk and in memory using hash tables.
- Execution: Hash build/probe drives joins, hash aggregation implements reductions, and block-nested scans handle sequential operations. In-place aggregation and reused hash structures are central to loop execution efficiency.
- Unified IR: All operators and query constructs, including Cypher-level predicates and GraphAlg matrix operations, coexist in a single IPR plan, facilitating cross-domain optimization (e.g., pushing WHERE clauses inside edge scans in matrix multiplications).
5. Performance Evaluation and Benchmark Results
AvantGraph implementation (“GAA”) is benchmarked against DuckDB+Python (“DDB”) and Neo4j’s Pregel (“N4J”) on LDBC Graphalytics workloads:
- Code Complexity: GraphAlg implementations for BFS, CDLP, PageRank, SSSP, and WCC average 12 LOC, versus ~36 LOC for SQL+Python, and ~80 LOC for Pregel/Java, reducing code size by 2–7×.
- Runtime Performance:
- BFS: GAA and DDB deliver sub-second runtimes on small graphs; N4J is 4–10× slower.
- CDLP: DDB leads slightly, followed by N4J; GAA is 3–5× behind due to a hash-aggregation hotspot identified for tuning.
- PageRank, SSSP, WCC: GAA is fastest, DDB second, N4J frequently outperformed or unable to scale to larger graphs.
- WCC and SSSP: GAA’s in-place aggregation outpaces DDB by 2–4× on large “small” graphs.
- Scalability and Preprocessing:
- On the 47M-edge OpenAIRE citation graph, “self-filter” scenarios see GAA 2–3× faster than DDB for >5 iterations and consistently faster than N4J, which requires full reloads per variant.
- “Deduplicate” scenarios benefit from hoisting heavy deduplication before the loop in GAA; DDB’s per-iteration recomputation slows performance, and N4J’s cost is amortized only after many iterations.
6. Integration, Limitations, and Future Directions
AvantGraph with GraphAlg delivers full expressiveness for defining established graph algorithms (PageRank, SSSP, WCC, label propagation) within a compact linear-algebraic DSL (10–20 lines per algorithm). Algorithms execute natively alongside queries, eliminating export/import steps and data staleness, and leverage advanced optimizations including static sparsity tracking, loop hoisting, and in-place updates.
Noted limitations include:
- CDLP underperformance due to hash aggregation bottlenecks; improved multi-threading is a development target.
- BFS on very sparse graphs may be limited by current I/O formats versus highly tuned columnar designs.
- The engine is presently single-node; distributed execution is planned.
- Standard SQL+CTE back-end generation is not currently implemented; supporting recursive CTE plans could broaden usability.
Future work aims to:
- Conduct user studies to quantify productivity gains attributable to the concise GraphAlg DSL.
- Integrate GraphAlg-to-SQL compilation exploiting new CTE extensions in PostgreSQL and DuckDB for portability.
- Expand the Loop node to distributed “shard+exchange” plans for scale-out analytics.
- Support streaming graphs and dynamic, incremental algorithms (e.g., in-place delta updates).
- Construct higher-level analytics libraries (graph kernels, algebraic reachability) on GraphAlg.
The AvantGraph system demonstrates that a minimalist linear algebra DSL compiled to relational algebra with sophisticated loop and sparsity optimization provides both the expressiveness of dedicated graph-analytics APIs and performance on par with specialized engines, establishing an effective paradigm for algorithmic support in graph databases (Graaf et al., 10 Jan 2026).