Source-linked AI summary
Relational-Core Graph Analytics Querying graphs at SQL scale, and why the node/edge model is a performance tax, not a truer picture of connected data
Gene Zhang
TL;DR
The paper addresses whether enterprise graph analytics needs a native graph engine and whether node/edge storage faithfully represents connected data. It translates Cypher onto native relational schemas for in-place execution, arguing that relational analytical performance and open SQL optimization avoid re-encoding overhead, while native engines retain advantages for deep OLTP traversal and mutating graphs.
Problem
The paper challenges the assumption that graph analytics requires a purpose-built engine and examines whether generic node/edge encoding is more faithful than relationships already explicit in relational schemas.
Method
The paper presents systems that translate Cypher directly onto native relational tables, columns, and foreign keys, executing in place while using ordinary SQL as the optimization surface.
Results
The paper reports that native relational execution avoids the re-encoding tax, while controlled comparisons and benchmark evidence show relational approaches can outperform native graph engines on analytical workloads.
Takeaways & Limitations
For analytical graph workloads over enterprise data, graph-query convenience can be combined with relational SQL execution without importing data into a separate graph store.
Takeaways & Limitations
The work is read-only and single-node; graph-native engines retain advantages for deep OLTP traversal and mutating graphs, while distributed execution remains open.
Abstract
from arXiv · showhide
A durable assumption holds that graph analytics requires a purpose-built graph engine, and that relational systems are ill-suited to connected data. We argue the opposite for the workloads enterprises actually run. A columnar relational engine fronted by a graph query language matches or exceeds native graph engines on analytical graph queries, and - decisively - scales past the point where in-memory graph engines fail. We further argue that the node/edge property graph is not a more faithful model of connected data but a re-encoding of relationships that already exist explicitly in relational tables; reconstructing them at query time is pure overhead. We present ClickGraph and its Databricks-dialect sibling DeltaGraph, systems that translate Cypher directly onto the native relational schema - the tables, columns, and foreign keys as they already exist - and execute in place on ClickHouse, Databricks, or in-process on lakehouse files, with no import and no separate cluster. Because the output is ordinary SQL, an underperforming query is an open optimization surface: it can be rewritten, and the engine itself extended. We support the argument with a peer system's own published benchmark, in which a columnar engine outruns Neo4j by two-to-four orders of magnitude, and with reproducible measurements across the LDBC Social Network Benchmark suite.
1 Introduction
The paper challenges the assumption that graph analytics requires a native graph engine, arguing that relational execution, native relational representations, and open SQL optimization better fit enterprise analytical workloads. It also limits this claim to read-only OLAP graph analytics, while recognizing a narrower advantage for native engines in low-latency transactional path lookups.
- Performance and scale: Columnar relational engines can apply mature storage, vectorization, and cost-based optimization directly to graph queries expressed as joins.Graph-native runtimes instead traverse node-and-adjacency-list stores tuple-at-a-time and must re-derive these techniques.
- Representation: Generic node/edge tables re-encode relationships already explicit in foreign keys, junction rows, denormalized columns, and polymorphic or composite-key references.ClickGraph translates directly onto these native relational patterns rather than reconstructing adjacency at query time.
- Openness: Translated queries retain an open optimization surface because SQL can be rewritten and the underlying relational engine can be extended with graph-specific optimizations.This leverages the broader relational-optimization toolkit rather than relying solely on bespoke graph traversal optimization.
- Why now: Enterprise graph workloads increasingly involve agents querying live relational warehouse and lakehouse data, making query-in-place translation more consequential as query volume and unpredictability grow.The paper frames copying enterprise data into a separate graph store as an accumulating cost.
- Scope: The scope is read-only OLAP graph analytics, while native engines retain a narrow advantage for low-latency, single-record path lookups on live, write-heavy transactional graphs.The paper explicitly excludes OLTP transactional traversal and does not claim relational execution wins for that workload.
2 Background and the graph-analytics landscape
The landscape separates graph systems by where graph data is stored and how engines execute queries. Prior work and standards support relational-core execution, while ClickGraph/DeltaGraph emphasize native-schema, query-in-place mapping as the distinguishing contribution.
- Where the graph lives: Three tiers distinguish native graph stores, relational engines over re-encoded node/edge tables, and translation layers querying relational data in place.Grail and GRainDB compile graph queries to SQL but still load graph data into overlays; PuppyGraph and ClickGraph/DeltaGraph use zero-import native-schema execution.
- Reference points: Prior systems establish relational-core graph execution, while this work extends it to native relational schemas rather than vertex/edge overlays.Grail and GRainDB compile to SQL but retain imported or overlaid graph representations.
- Standards and prior systems: SQL/PGQ places graph pattern matching and path finding inside the relational engine, treating property graphs as view-like objects over existing tables.Oracle PGQL preceded the SQL:2023 standard, while Oracle Database 23ai and DuckPGQ implement the relational-core approach.
- This paper’s position: ClickGraph/DeltaGraph extend relational-core graph querying through native-schema patterns over an existing columnar warehouse, with Cypher and Bolt front ends and no separate cluster.The differentiator is native-schema mapping and zero-cluster, query-in-place execution rather than the general relational-core idea.
- Engine architecture: Analytical architecture is a separate axis from storage location: columnar and vectorized systems differ from pointer-, row-, and LSM-based engines.This separation prevents “relational versus graph” from conflating execution architecture with graph representation.
- Performance landscape: DuckPGQ reports that it and Umbra stay within an order of magnitude while both consistently outperform Neo4j, independently corroborating relational-core performance claims.Kuzu provides a positive comparator with columnar, vectorized execution and a Cypher front end, but stores its graph natively.
3 Motivation and rationale
The paper separates execution-engine performance from representation overhead: relational engines bring vectorized analytical execution, while native-schema translation avoids re-encoding relationships already explicit in relational tables.
- 3.1 The re-encoding tax: Relational schemas encode relationships explicitly, whereas node/edge re-encoding reconstructs them at query time and charges that work on every query.The re-encoding is information-preserving but performance-lossy, especially for n-ary relationships that require additional objects and joins.
- 3.2 Why graph-native storage resists analytical acceleration: Native graph engines use tuple-at-a-time pointer chasing, forfeiting vectorization and making analytical multi-hop execution difficult to accelerate.Relational engines can apply decades of columnar storage, vectorized execution, and optimization work once graph queries are expressed as joins.
- 3.2 Why graph-native storage resists analytical acceleration: The three storage forms rank by analytical performance as native relational schema, generic relational node/edge tables, then native adjacency-list storage.Generic node/edge tables retain set-oriented execution but pay a re-encoding tax; native adjacency lists suffer the larger execution-model penalty.
- 3.3 Why translation is the right default: SQL translation is presented as the default because it moves no data, adds no system, reuses mature tooling, and leaves query and engine optimization surfaces open.The stated boundary is that tight OLTP traversal and currently unbounded-depth recursive-CTE paths can still favor graph-native engines.
- 3. Motivation and rationale: The paper isolates two claims experimentally: relational execution scales better than graph-native execution, and native-schema translation beats re-encoded node/edge storage on one engine.The first changes only the engine; the second holds data and engine fixed while changing representation.
4 System design: ClickGraph and DeltaGraph
ClickGraph and DeltaGraph translate Cypher into dialect-specific SQL over existing relational or lakehouse data, supporting multiple deployment modes without a separate graph store. Their design centers on schema-native mappings, a shared translation pipeline, and compatibility with established graph clients and agent workflows.
- 4. System design: ClickGraph and DeltaGraph: ClickGraph translates Cypher into ClickHouse SQL, while DeltaGraph targets Databricks and Spark dialects across server, embedded, remote, and SQL-only modes.The modes cover remote engines, in-process execution through chdb, and translation without execution.
- 4. System design: ClickGraph and DeltaGraph: The six-stage pipeline parses, plans, optimizes, renders, generates SQL, and executes against ClickHouse or Databricks.Its two central design elements are schema-native mapping and a dialect-neutral backend built around a SQL intermediate representation and dialect layer.
- 4.1 Zero-ETL and zero-cluster: the edge over PuppyGraph: Unlike a dedicated zero-ETL tier, ClickGraph pushes graph queries into an existing ClickHouse or Databricks engine, or runs them in-process through chdb with no cluster.The comparison is operational: PuppyGraph requires a dedicated cluster even though both systems avoid data import.
- 4.2 Schema-native mapping: The graph catalog maps five relational schema patterns directly to existing tables, columns, and foreign keys rather than imported node/edge copies.Composed patterns include composite identifiers, denormalized edges, and polymorphic edges, requiring correct SQL for each combination.
- 4.4 The real problem: one translation path, not per-flag branching: Five schema patterns compile into six SQL strategies through one analysis point, with exhaustive downstream matching instead of scattered raw-flag branches.The design addresses regressions from ad-hoc branching by centralizing schema decisions and enforcing the single path with a ratchet test.
- 4.5 Ecosystem: adoptable, not just correct: The system supports Neo4j Bolt v5.8 and verified graphical clients, including Neo4j Browser with full result parity on ClickHouse and Databricks backends.The implementation also packages schema-discovery and graph-query skills with an MCP server, while chdb supports exploratory queries over lakehouse files.
5 Making translated SQL fast
ClickGraph makes translated SQL tunable at the query-shape, recursion-strategy, and engine levels. Exact-length paths already become optimizer-friendly join chains, while bounded and unbounded paths remain the main recursion frontier.
- Query-shape optimization: ClickGraph applies projection and filter push-down, anchor selection, and statistics-informed planning to generated SQL.
- Recursion strategy: Exact-length paths render as flat inline-join chains, while bounded and unbounded paths use recursive CTEs.Flat joins can be reordered, filtered through, and parallelized; recursive CTEs execute as sequential fixpoints.
- Engine optimization: Graph-specific joins, indices, worst-case-optimal joins, and factorized processing can extend the underlying SQL engine.
- Recursion strategy: Bounded ranges could be unrolled into UNION ALL chains, extending the existing optimization beyond exact-length paths.
6 Evaluation
The evaluation combines reproducible ClickGraph measurements, peer benchmark evidence, and a controlled representation study. ClickGraph executes 26 of 41 LDBC queries with sublinear scaling, while the comparisons show large columnar advantages and a measurable node/edge re-encoding tax, subject to clear scope limits.
- Evaluation design: ClickGraph’s evaluation separates reproducible measurements, peer published figures, controlled micro-benchmarks, and a whole-system comparison left for future work.
- LDBC SNB: 26 of 41 LDBC queries execute end-to-end, with passing medians of 23 ms for Interactive Short, 130 ms for Interactive Complex, and 367 ms for Business Intelligence.
- LDBC SNB: 2.5× median latency growth accompanies a 10× data increase at SF10, with identical coverage and no memory exhaustion or timeout.
- LDBC SNB: The 15 non-passing LDBC queries cluster into defined boundaries involving unsupported procedures, syntax, mappings, planner composition, and recursive-CTE endpoint reuse.
- OnTime benchmark: 2–4 orders of magnitude separate the columnar engine from Neo4j in PuppyGraph’s published OnTime benchmark, including approximately 4,300× and 5,000× comparisons.ClickGraph’s measurements are a band comparison because its dataset window and hardware differ from the peer benchmark.
- Validity limits: The Neo4j comparison relies on PuppyGraph’s published figures, and the evaluation is single-node with heterogeneous hardware and no direct TigerGraph comparison.
- Representation study: 2.4–6.8× faster native FK-join SQL isolates the re-encoding tax on identical PostgreSQL data and results.The whole-graph scan increases from 0.56 s to 2.2 s after re-encoding into Apache AGE node/edge tables.
7 Business and operational benefits
ClickGraph and DeltaGraph provide operational benefits by querying existing warehouse or lakehouse data in place. They reduce infrastructure and synchronization work while preserving existing relational governance and scale.
- Operational simplicity: In-place querying eliminates ETL into a graph store and removes the need to operate and synchronize a second data system.
- Operational simplicity: Existing access controls, governance, backups, and warehouse elasticity apply unchanged to the graph workload.
- Deployment choice: The decision guide favors ClickGraph or DeltaGraph when data outscales one graph engine, and native SQL when data already fits one engine.
- Deployment choice: Underperforming translated queries remain open to SQL or underlying-engine optimization using relational techniques.
8 Discussion, limitations, and future work
The paper limits its claims to read-only analytical workloads and identifies native advantages for deep OLTP traversal and mutation. Future work targets distributed execution, bounded-range path unrolling, and iterative graph workspaces.
- Limitations: Graph-native engines retain advantages for deep OLTP traversal and mutating graphs, while this work evaluates read-only execution.
- Limitations: The single-node evaluation leaves distributed execution as a natural follow-on question.
- Future work: Bounded ranges such as *1..3 could become UNIONs of fixed join chains, leaving only genuinely unbounded paths recursive.
- Future work: Iterative graph workspaces could map temporary result tables into new graph schemas for chained Cypher analysis and agent tool calls.
9 Conclusion
The paper argues that recent advances have strengthened the case for reconsidering specialized graph engines in enterprise workloads. Its approach is to translate graph queries onto native relational schemas, execute them in place, and retain SQL as an open optimization surface.
- SQL's absorption of property-graph querying and the ubiquity of columnar engines strengthen the case against specialized graph engines for many enterprises.The paper also frames graph traversal over enterprise data as a routine demand rather than a specialist one.
- ClickGraph extends relational-core graph stores by querying relationships already held in tables rather than layering graph queries over a separate graph representation.It translates Cypher onto the native schema and executes in place.
- For data volumes beyond graph-engine scale, the paper combines graph-query convenience with SQL analytical performance; for smaller volumes, plain SQL may suffice.Translated queries and the underlying engine remain open to further optimization.