Raqlet: Cross-Paradigm Recursive Compilation

• Raqlet is a cross-paradigm compilation framework that enables semantic-preserving translation among recursive SQL, property graph query languages, and deductive engines.
• It employs a multi-stage pipeline—using PGIR, DLIR, and SQIR—to perform static analysis, optimization, and schema transformation for consistency and portability.
• Empirical results suggest that its compiled queries often outperform native executions, underscoring Raqlet's role as a potential golden reference for SQL:2023 SQL/PGQ and GQL standards.

Searching arXiv for the specified paper to ground the article. Raqlet is a source-to-source compilation framework for recursive queries that bridges three fragmented ecosystems: recursive SQL, property-graph query languages such as Cypher and GQL, and Datalog or other deductive engines. Its central design is a cross-paradigm lowering pipeline in which Cypher or SQL/PGQ input is translated to PGIR, then to DLIR, and finally to SQIR and a target language output. PGIR captures graph-pattern structure, DLIR provides a Datalog-inspired semantic core grounded in least-fixed-point and stratified semantics, and SQIR acts as a recursive-SQL-oriented target representation. The framework is explicitly positioned not as another execution engine, but as a common compilation and semantic basis intended to support portability, static analysis, recursive-query optimization, and a possible “golden reference implementation” role for SQL:2023 SQL/PGQ and GQL (Shaikhha et al., 6 Aug 2025).

1. Problem setting and motivation

Raqlet addresses fragmentation in recursive querying systems across relational, graph, and deductive paradigms. The motivating observation is that recursion has become important across analytics, graph processing, program analysis, and reasoning, while the languages and engines supporting it remain inconsistent in data model, expressiveness, optimization support, and semantics (Shaikhha et al., 6 Aug 2025).

That inconsistency creates a portability problem. A query written for one paradigm often cannot be moved directly to another without manual rewriting, and even when apparently similar features exist, their semantics may differ enough to change answers or termination behavior. Raqlet’s response is to provide a common compilation and semantic core that translates across paradigms while preserving meaning, rather than relying on pairwise manual reformulations between individual systems.

The framework is also situated relative to recent standardization efforts. SQL:2023’s SQL/PGQ and the GQL standard provide a common foundation for querying graph data within relational and graph databases, but real-world support remains inconsistent across systems. Raqlet is therefore framed as a bridge between standards and implementations: it seeks to give recursive and graph query constructs a single semantic account even when backend support is uneven.

2. Compilation architecture

Raqlet follows a three-stage compiler organization: a frontend that parses an input query, a middle end that lowers and analyzes it through intermediate representations, and a backend that unparses to a target language. The paper describes the pipeline as:

Stage	Representation	Role
Frontend	Cypher or SQL/PGQ input	Parsing and normalization
Middle end	PGIR $\rightarrow$ DLIR $\rightarrow$ SQIR	Lowering, semantic analysis, transformations
Backend	Datalog or recursive SQL output	Target-specific unparse

The pipeline is explicitly given as:

Cypher or SQL/PGQ input → PGIR → DLIR → SQIR → target language output

Most reasoning and optimization are intended to occur in the Datalog-inspired IR. This design choice reflects the paper’s claim that DLIR provides a mathematically clean semantics for recursion and therefore serves as the principal locus for semantic-preserving translations, static analyses, and performance-oriented rewrites (Shaikhha et al., 6 Aug 2025).

The backend behavior differs by target. Datalog output is direct. SQL output is produced by mapping each non-recursive rule to a CTE and each recursive rule to a recursive CTE; the final SQL program is then a sequence of CTEs followed by a SELECT from the last CTE. In the running example, the DLIR rules become V1, V2, and V3, and the last query selects distinct rows from V3.

3. Intermediate representations and schema transformation

PGIR, or Property Graph IR, is inspired by the graph-pattern side of Cypher and GQL and is designed to capture the essential structure of graph pattern matching and recursive graph navigation. The paper states that PGIR is inspired by GPC and extends it to support the core Cypher features needed for LDBC SNB read workloads, including aggregation and shortest-path finding (Shaikhha et al., 6 Aug 2025).

PGIR represents a query as a sequence of clause constructs such as MATCH, WHERE, and RETURN. During lowering, the parser normalizes the input query into patterns, filters, and aliasing, and these are mapped into PGIR’s clause structure. In the paper’s example, a Cypher pattern with a Person node, an IS_LOCATED_IN edge, a City target node, and projected return items is decomposed into a MATCH over the graph pattern, a WHERE predicate n.id = 42, and a RETURN over the projected outputs.

DLIR is the key semantic layer. It is a Datalog-inspired intermediate representation that supports recursion with negation and aggregation and represents a query as a sequence of rules, each with an IDB head and a body of atoms. The paper emphasizes that translations from PGIR to DLIR are defined construct-by-construct and use schema information to infer variable positions and types. In the running example, the MATCH, WHERE, and RETURN clauses are lowered into three Datalog-style rules and an .output Return declaration.

Raqlet also includes a schema transformation from property-graph schema to a Datalog-style schema. For Cypher, a property-graph schema G is translated into a DL-Schema consisting of EDB predicates for every node and edge type. The paper gives the following example:

CREATE GRAPH { ( personType:Person {id INT, firstName STRING, locationIP STRING}), ( cityType:City {id INT, name STRING}), (: personType )-[ locationType: isLocatedIn {id INT} ]->(: cityType ) }

which becomes:

.decl Person(id: number, firstName: symbol, locationIP: symbol) .decl City(id: number, name: symbol) .decl Person_IS_LOCATED_IN_City(id1: number, id2: number, id: number)

This transformation enables the same graph schema to be treated as a relational or logical fact schema, thereby supporting execution and reasoning in Datalog or SQL settings. A plausible implication is that schema-level portability is as important as query-level portability in the framework’s overall design.

4. Semantic basis and preservation claims

The paper’s principal correctness notion is semantic-preserving translation. Translations from Cypher or SQL/PGQ to DLIR are designed to preserve meaning, and DLIR is presented as the formally specified core of the system. Its semantic basis is drawn from Datalog’s least-fixed-point semantics, especially stratified Datalog and extensions such as Datalog$^o$, which are used to provide a disciplined account of recursion, negation, and aggregation (Shaikhha et al., 6 Aug 2025).

A central claim is that recursive SQL and graph languages currently lack complete or consistent formal semantics in practice, especially across implementations and in the presence of features such as NULLs and recursion. Once a query has been compiled into DLIR, by contrast, its meaning is anchored in a well-known logical semantics. This is the basis for the paper’s claim that Raqlet can serve as a “golden reference implementation” for standards such as SQL:2023 SQL/PGQ and GQL.

The paper does not present a fully mechanized proof of correctness for the complete lowering pipeline. Instead, it describes the formal semantics section as conceptual rather than theorem-heavy and states an intention to formalize DLIR semantics, the pipeline, and optimizations in proof assistants such as Rocq/Coq or Lean. That limitation is explicit and should not be confused with a claim of machine-checked end-to-end verification.

The paper also notes a practical equivalence caveat for Cypher queries: because deductive engines typically use set semantics and do not support ordering or limiting in the same way, ORDER BY and LIMIT are removed and RETURN DISTINCT is used to obtain semantic equivalence across backends. This directly addresses a common misconception that syntactic translation alone is sufficient for cross-system equivalence; in Raqlet, backend semantic mismatches must be handled explicitly.

5. Static analyses and recursive-query optimization

Raqlet is intended not only as a translation layer but also as an analysis and optimization platform centered on DLIR. The stated rationale is that analyses implemented once at the DLIR level can be reused across multiple frontends and backends (Shaikhha et al., 6 Aug 2025).

The analyses described in the paper are the following.

• Linearity: checks whether recursion is linear, that is, whether each recursive rule has a single recursive predicate. This matters because many backends only support linear recursion. The framework can reject unsupported non-linear queries or rewrite them into linear form when possible.
• Mutual recursion: detects cycles among recursive predicates. This is used both to reject unsupported backends and to enable rewrites for mutually recursive queries.
• Monotonicity: determines whether the recursive query is monotone under set inclusion. This matters for convergence and for safely handling negation and aggregation.
• Termination analysis: detects possible nontermination, including via interpreted functions over unbounded domains or bag semantics.

The optimization repertoire likewise operates at the IR level.

• Inlining: expands intermediate views or IDBs into the places where they are used, subject to safety conditions such as not inlining rules involved in aggregation or negation.
• Dead rule elimination: removes intermediate rules that no longer contribute to the final result after inlining.
• Pushing operators past recursion: includes magic-set transformation and the FGH rule.
• Semantic join optimizations: exploit integrity constraints; in property graphs, this includes eliminating joins on disjoint keys inferred from PG-Schema.
• Code generation: the paper notes that additional IRs could carry more procedural detail to support low-level code generation and JIT-style query compilation.

The paper’s worked optimization example illustrates the general mechanism. Match1 is folded into Where1, and Where1 into Return; after dead-rule elimination, only Return remains. This demonstrates that optimization is decoupled from the source language: the same rewrite logic can apply whether the originating query was written in Cypher, SQL, or Datalog.

6. Empirical evaluation, standards role, and limitations

The implementation and evaluation are described as preliminary but illustrative. The reported experiment uses the LDBC Social Network Benchmark, specifically short query 1 and complex query 2 at scale factor 10. It compares the original Cypher query on Neo4j 5.27.0 with translated Datalog on Soufflé 2.4.1 and translated SQL on DuckDB 1.1.3 and Tableau Hyper API 0.0.21200, running on an AMD Ryzen 9 5950X with 64 GB RAM and Ubuntu 24.04.1 (Shaikhha et al., 6 Aug 2025).

The paper reports the following times.

Benchmark	System	Reported time(s)
SQ1	Neo4j	72.17 ms
SQ1	Soufflé	0.05 ms unoptimized / 0.02 ms optimized
SQ1	DuckDB	24.25 / 1.78 ms
SQ1	Hyper	0.89 / 0.78 ms
CQ2	Neo4j	87.85 ms
CQ2	Soufflé	11.70 / 11.31 ms
CQ2	DuckDB	33.18 / 4.01 ms
CQ2	Hyper	215.85 / 168.16 ms

The authors frame these measurements as preliminary rather than as a full benchmark suite. Even so, the reported results support two limited conclusions stated in the paper: translated Datalog and SQL versions were often faster than the original Cypher query, and optimized versions were consistently better than unoptimized ones.

The standards significance follows from the semantic argument rather than from the benchmark. Raqlet is aligned with SQL:2023 SQL/PGQ and GQL and is intended to provide a canonical semantic bridge between those standards and heterogeneous implementations whose recursive semantics, NULL handling, and feature support may diverge.

Several limitations are stated explicitly. The system is not fully implemented for all desired frontends and backends, and some languages are only partially supported. The paper does not yet provide a fully formal, machine-checked semantics for the entire compilation pipeline or for all optimizations. The experimental evaluation is limited to a few queries and backends, with a more extensive performance study left for future work. Finally, unifying recursive query systems remains challenging because their differences are not only syntactic but also semantic and operational, especially in the presence of NULLs, bag semantics, advanced aggregation, and backend-specific execution strategies. These limitations suggest that Raqlet is best understood as a semantic and compilation framework whose core concepts are established, while full coverage and formal closure remain ongoing objectives.