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
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
Lineage graph
Paper → model → repo connections mined from source citations (Tier-1 exact match).
Why these links exist
Every edge carries a method, confidence, and the source snippet that justified it — so bad links are debuggable.
- PossiblePossibly related (embedding) · 57%Slater – Low-memory graphdb designed for read-heavy graphs →
- PossiblePossibly related (embedding) · 53%YouTrackDB is a general-use object-oriented graph database →
- LinkedLinked via arxiv author · 85%Gene Zhang →
“Relational-Core Graph Analytics Querying graphs at SQL scale, and why the node/edge model is a performance tax, not a tr”
