For about fifteen years, the conventional wisdom in the database world has been: if your data is "connected" — social networks, fraud rings, supply chains, knowledge graphs — you need a specialized graph database like Neo4j or TigerGraph. Relational databases (the SQL kind) were supposedly the wrong tool for the job, because joining tables together to trace relationships was slow and awkward compared to a purpose-built engine that stores data as nodes and edges.

This paper picks a fight with that assumption, and comes armed with benchmarks.

The author, Gene Zhang, argues something surprisingly bold: a modern columnar relational engine (the kind that stores data column-by-column instead of row-by-row, used in analytics warehouses like DuckDB, ClickHouse, or Snowflake) — when you put a graph query language on top of it — actually matches or beats native graph engines on real analytical workloads. And more importantly, it keeps working at scales where in-memory graph engines simply run out of room and crash.

The two big claims:

• Performance parity or better. On the kinds of graph queries enterprises actually run (aggregations across relationships, multi-hop traversals with filters), a columnar engine holds its own. The overhead people assumed relational systems paid turns out to be small — or negative — because columnar engines have spent two decades getting extremely good at joins.
• Scale is decisive. Native graph engines typically want the whole graph in memory. Relational systems don't. So once your dataset gets big enough, the graph engine falls over and the relational one keeps going.

The deeper philosophical claim is even spicier. The property graph model (nodes with properties, edges with properties) isn't a "truer" representation of connected data — it's just a representation, and one that imposes a real cost. Every relationship gets its own object with its own storage and indexing overhead. The paper argues this is a performance tax disguised as intuition. Relations between things, Zhang says, are perfectly well captured by tables and foreign keys; you just need a query language that doesn't make you write ugly SQL to express traversals.

The proposed compromise: keep the friendly graph query syntax (something Cypher-like) as the developer interface, but compile it down to run on a columnar relational engine underneath. Best of both worlds — expressive queries, but the mature storage and execution machinery of the SQL world.

If Zhang is right, a lot of specialized graph database deployments are solving a problem their organization already had a better tool for. That's a big "if," but the argument is well-motivated by where actual enterprise graph workloads sit: mostly analytical, mostly too big for RAM.