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
cs.DB · cs.AI · cs.PL
Quick verdict
Persuasive case for Cypher-to-SQL over native relational schemas; honest limits, but headline speedups rest on vendor charts, not a controlled head-to-head.
Summary
This position-plus-systems paper argues that enterprise graph analytics does not require a graph-native engine: translating Cypher to SQL and executing it directly on the native relational schema of an existing columnar warehouse (ClickHouse, Databricks) matches or exceeds native engines on analytical queries, while re-encoding relationships that already exist as foreign keys and junction rows into generic node/edge tables is a performance tax. The author implements ClickGraph and its Databricks sibling DeltaGraph — zero import, zero separate cluster — mapping five real-world schema patterns onto six join strategies via a single exhaustive dispatch. On LDBC SNB SF1/SF10, 26 of 41 official queries execute, with all 15 failures categorized (missing procedures, unimplemented subqueries, recursive-CTE limits); median latency grows only 2.5x for 10x data, though recursive query BI3 degrades ~130x. The Neo4j comparison rests entirely on PuppyGraph's published benchmark (columnar 2-4 orders of magnitude faster); ClickGraph's own OnTime numbers are a band comparison on a different data window and host. A controlled PostgreSQL 18.6 microbenchmark isolates the representation claim: native FK-join SQL answers identical queries 2.4-6.8x faster than the same graph in Apache AGE node/edge tables. Limitations: single-node only, no direct Neo4j or TigerGraph measurement, vendor-chart dependence, small scale factors.
Review complete
Assessment at a glance
5
risk flags identified
● high 0
● medium 3
● low 2
5 strengths · 4 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- A columnar relational engine fronted by Cypher-to-SQL translation matches or exceeds native graph engines on analytical graph queries and scales past where in-memory graph engines fail (§1, §6).
- The node/edge property-graph re-encoding is a performance tax: translating onto the native relational schema avoids reconstructing relationships (foreign keys, junction rows) the schema already materializes (§3.1, §6.1).
- ClickGraph/DeltaGraph map five real-world schema patterns onto six join strategies through one exhaustive dispatch, achieving correctness (402 openCypher TCK scenarios, 22 LDBC parity checks) with zero import and zero separate cluster (§4).
- On a controlled PostgreSQL 18.6 microbenchmark, native FK-join SQL answers identical queries 2.4-6.8x faster than the same graph re-encoded into Apache AGE node/edge tables (§6.1, Table 6).
Strengths
Clean variable isolation
The Table 1 (storage tier) / Table 2 (engine architecture) taxonomy explicitly separates the two confounded variables, and §6.1's controlled microbenchmark holds engine, hardware and data fixed — same PostgreSQL 18.6 instance, identical result counts verified per query — making the 2.4-6.8x re-encoding tax the paper's most defensible novel experiment.
Unusually honest negative reporting
All 15 failing LDBC queries are categorized into five named causes (5 GDS/APOC procedures, 2 CALL{} subqueries, 2 unfilled polymorphic mappings, 1 chained undirected optional hop, 5 recursive-CTE-across-barrier shapes) rather than trimmed; BI3's ~130x SF1-to-SF10 regression is presented as a plan pathology, and threats to validity are enumerated in §6.
Real, auditable engineering contribution
Strong grounding in prior art and the standard
Practical compatibility surface
Weaknesses
Headline comparison is borrowed and uncontrolled
Central scaling claim never measured
No statistical dispersion anywhere
Single-node evidence for a SQL-scale thesis
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
A position-plus-systems paper in cs.DB (single author; system: ClickGraph, with DeltaGraph as the Databricks-dialect sibling; code on GitHub). It advances two explicitly separated claims (§3.5): **Claim A (engine)** — columnar, vectorized relational execution outperforms graph-native pointer-chasing engines on analytical graph workloads; **Claim B (representation)** — translating Cypher onto the *native* relational schema (foreign keys, junction rows, denormalized columns, polymorphic edge tables, composite keys — §4.2's five patterns) beats re-encoding the same data into generic node/edge tables. Scope is bounded up front (§1): read-only OLAP only; low-latency transactional point lookups are conceded to native engines. The GraphRAG motivation (§1.1) supplies timing and framing but no measurements.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 5 strengths & 4 weaknesses, analyzed in detail
- 5 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What is ClickGraph?
ClickGraph is an open-source engine (github.com/genezhang/clickgraph) that translates Cypher graph queries into SQL executed directly on an existing ClickHouse or Databricks warehouse, reading native tables, columns and foreign keys with no data import and no separate graph cluster; DeltaGraph is its Databricks/Spark-dialect sibling.
How much faster is a columnar SQL engine than Neo4j for graph analytics?
According to the PuppyGraph-published OnTime benchmark cited in the paper, roughly 370x to 5,000x per query (Neo4j approx. 41-515 s vs sub-second cached columnar latencies). Note the paper's own system was not directly compared against Neo4j on identical hardware — that comparison is borrowed from vendor charts.
What is the re-encoding tax in this paper?
The measured slowdown from copying relational data into generic node/edge graph tables: on one PostgreSQL 18.6 instance (100K vertices, 2M edges), native foreign-key-join SQL answered the same queries 2.4x to 6.8x faster than the identical graph loaded into Apache AGE, with identical result counts verified.
Which LDBC SNB queries does ClickGraph fail on?
15 of 41 official queries, in five categorized groups: five need GDS/APOC graph-procedure libraries, two need CALL{} subquery syntax, two need an unfilled polymorphic edge mapping, one needs a chained undirected optional hop, and five involve recursive-CTE endpoint references across WITH/UNWIND barriers.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- The rendered plots (Fig. 2-5) are available only as extracted captions and values; chart internals such as per-query dot placements in Fig. 5 could not be visually inspected.
- Table 5's Neo4j/PuppyGraph latencies are the author's own approximations read from vendor charts, so exact source values are unverifiable from this text alone.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.