We translate Cypher to SQL and push it down to ClickHouse or Databricks. No graph database. No data movement. No second compute engine. The graph question, answered where the data already lives — at a scale the graph engines can't reach.
The wedge — three things we add
A pure translator. 100% of execution runs inside the warehouse you already operate, secure, and pay for. There is no engine to size, scale, or bill.
Nothing is imported, copied, or flattened. Your existing tables — warehouse or open lakehouse formats (Iceberg, Delta, Parquet) — are the graph, with their real relationships intact. Data never leaves the platform boundary.
We store nothing. Our scale ceiling is the warehouse's — petabyte-native. The graph engines cap at what fits in RAM.
Where this matters most — GraphRAG
GraphRAG needs two retrievals over your knowledge: semantic (“chunks similar to this query” → vector search) and structural (“traverse from these entities to related facts” → graph). ClickHouse and Databricks already ship native vector search.¹⁰¹¹ Today, teams do the semantic half in the warehouse and export to Neo4j/Neptune for the structural half — a second store, an ETL pipeline, a sync lag, a governance gap. The vectors are already home; the graph traversal can live there too.
RAG data is a live knowledge base. Exporting to a graph DB makes answers stale by the ETL lag. We query where fresh data lands — no ingestion, no lag.
Collapse graph into the store that already holds the vectors. One system to run and secure, not vector DB + graph DB + sync glue.
The context sent to the LLM must contain only what the user is authorized to see. A separate graph store is a second RBAC surface to get right. We inherit the warehouse's access controls.
Enterprise knowledge bases outgrow a ~1 TiB in-memory graph engine. Your GraphRAG graph is as large as your warehouse — the same tables you already trust.
Honest scope: the warehouse does the embeddings and the ANN index — we're the graph half that completes the pair, not a vector database. Retrieval + bounded graph expansion is the ready path; heavier graph-algorithm summarization (e.g. community-based GraphRAG) is where the roadmap goes next — see below.
A flagship vertical — security graph at scale
Network flows, DNS, auth logs, cloud audit trails — petabytes of it, already landing in ClickHouse or the lakehouse, ingested at millions of events per second. The questions security teams ask are inherently graph questions: lateral movement (which host reached which host reached which), blast radius (what can this compromised identity touch), attack paths, threat propagation. Today they want graph queries on this data but can't — you cannot move a petabyte of flow logs into a graph database. So the graph question goes unasked, or gets asked on a stale, sampled export.
PB of telemetry can't fit a ~1 TiB in-memory graph engine. Pushdown queries it in place, at the warehouse's scale — the only place the query can actually run.
A stale security graph misses an active intrusion. Export-then-query adds ETL lag exactly when minutes matter. We query where events land — zero ingestion lag.
Standing up a graph store means a second, separately-governed copy of your most sensitive data. Querying in place keeps one governed source under existing controls.
Lateral movement, blast radius, entity resolution — bounded traversal + pattern-match + aggregate. Exactly the query shapes pushdown wins.
Not a slide — already modeled. ClickGraph ships Zeek network-security schemas out of the box: IP, Domain, ExternalIP entities over connection, DNS, and resolution logs (REQUESTED, RESOLVED_TO, ACCESS edges) — graph queries over raw security telemetry, no import step.
The wedge that's actually ours
Query-in-place is a crowded claim — others make it too. The difference is one level deeper: other engines are zero-ETL but still deploy their own distributed graph compute engine beside your data. You run it, scale it, pay for it. We deploy nothing that executes: Cypher becomes SQL, and your warehouse does the work.
The graph queries where native engines beat SQL are precisely the queries that can't reach your data scale. Deep traversal and graph algorithms need the working graph resident in memory — so it must fit in one engine's RAM. At hundreds of TB to petabytes, it physically can't.
The scale ceiling — the analytics engines are in-memory by design
The two engines purpose-built for graph analytics both hold the whole graph in RAM. That's not incidental — iterative algorithms need it. It's also why they stop long before warehouse scale.
| Engine | Architecture | Ceiling | At 100s TB – PB |
|---|---|---|---|
| Neptune Analytics what nx-neptune imports into |
Entire graph in-memory, provisioned in m-NCU (~1 GiB each) |
~1 TiB 1024 m-NCU max |
100–1000× short |
| Neo4j GDS | Algorithms run entirely in heap; heap ≈ 90% of one machine's RAM | Single-box RAM estimate-and-abort |
can't hold it |
| Neptune Database | Distributed storage — but OLTP, not analytics | 128 TiB incl. indices + logs |
< 1 PB, wrong shape |
| ClickGraph / DeltaGraph | Pushdown to the warehouse — stores nothing | Warehouse ceiling PB-native |
scales with the warehouse |
On Neptune Analytics, even MATCH (n) RETURN count(n) can run out of memory — counting all vertices “is not memory bounded.”⁴ A system where counting your nodes can OOM is not a system for petabyte data. AWS truthfully markets it as analyzing tens of billions of connections — that's ~1 TiB of RAM. Your data is 100–1000× that. Their number is real at their scale; your scale is where their scale ends.
The honest map — it's not graph vs SQL, it's query shape
We don't claim to be faster at everything. We claim the right tool per query shape — and that most real “graph analytics” is the top row.
The reframe: “graph algorithms” and “real-time” are in tension. The heavy algorithms are offline batch. The real-time graph workloads are pattern-matching + aggregation — exactly the shape pushdown wins, on data too fresh and too large to have been imported anywhere.
Traversal — we can do what they do, plus what they can't
Variable-length paths compile differently by shape. We already emit MPP-parallel join chains for exact hops; bounded ranges are a join-expansion optimization on the roadmap; unbounded traversal is a capability some SQL backends structurally lack.
| Traversal | ClickGraph / DeltaGraph | Engines on StarRocks-class SQL backends |
|---|---|---|
Exact *N..N |
chained joins today MPP-parallel, no recursion | Join expansion |
Bounded *1..3 |
roadmap compile to UNION ALL of fixed-hop joins |
Join expansion — the only option available |
Unbounded *1.. |
native recursive CTE on ClickHouse & Databricks | not expressible in-engine |
The honest boundary: recursive CTEs are row-iterative on ClickHouse — slower than vectorized scans, and best replaced by join expansion for bounded ranges (our roadmap).⁷ But unbounded arbitrary-depth traversal is something StarRocks-class backends can't express at all: StarRocks has no WITH RECURSIVE — the feature was requested and left unimplemented.⁹ We have both strategies; that class of engine has one. And unbounded transitive closure over a petabyte is expensive for everyone — which is why it belongs to a dedicated engine on a snapshot, not to any warehouse.
Openness — ask what runs on your data, and whether you can read the answer
Graph engines are usually opaque — you trust that a plan is good and that your data is handled well. We're a translator, and every query we generate is inspectable before it runs.
Point a skeptic at sql_only and they see exactly what will run on their ClickHouse or Databricks — the joins, the predicates, the pushdown. A closed-source engine asks you to trust a box you can't open: what its engine does, and where your data is processed. When you evaluate any graph engine, ask what it's built on and whether you're allowed to know. We're open source; the SQL is yours to read.
The honesty that makes the rest credible. Warehouse-native graph is an identity, not just an upside — you inherit the warehouse's scale and governance and its traversal-performance profile.
Algorithms already run in-warehouse — and the ceiling is ours to raise. ClickGraph ships PageRank (CALL pagerank(...)) and shortest path (shortestPath / allShortestPaths) today, generated as SQL / BFS recursive CTEs over your tables. A whole family of graph algorithms is iterated JOIN + GROUP BY over a semiring — exactly what a vectorized warehouse does best — so pushing further is open road: semiring aggregate functions, keyed/settled-set recursion, and iterated-fixpoint execution can bring more of the family inside the warehouse, at a scale the in-memory engines can't reach.
Sources — every competitive claim is first-party or the vendor's own public docs
WITH RECURSIVE feature request, unimplemented. github.com/StarRocks/starrocks/issues/34616ClickGraph & DeltaGraph — read-only Cypher-to-SQL graph query engines · v0.6.8 (DeltaGraph preview). Figures current as of publication; vendor ceilings change over time — verify against the linked docs. Comparative claims describe publicly documented behavior of named technologies, not any vendor's non-public internals.
All third-party names and marks are the property of their respective owners and are used here for identification and comparison purposes only. ClickHouse is a trademark of ClickHouse, Inc. Databricks and Delta Lake are trademarks of Databricks, Inc. Amazon Neptune and AWS are trademarks of Amazon.com, Inc. or its affiliates. Neo4j, Cypher, and Bolt are trademarks of Neo4j, Inc. Apache Spark, Iceberg, Hudi, and Parquet are trademarks of the Apache Software Foundation. StarRocks, PuppyGraph, TigerGraph, and other named products are trademarks of their respective owners. ClickGraph and DeltaGraph are independent projects and are not affiliated with, sponsored by, or endorsed by any of these companies.