Graph Versus Relational Infrastructure for Social Network Analysis at Community Scale: Traversal, Centrality, Community Detection and the Data Path to Graph Neural Networks

Counts differ because each database indexes a different set of publications. We treat OpenAlex as the canonical count; Google Scholar is not shown (no API, and crawling it violates its ToS).

Centrality, community and reach analyses of social platforms are graph traversals whose latency depends on the underlying data infrastructure. This paper compares a native graph engine (Neo4j 5.26 with the Graph Data Science library) and a relational engine (PostgreSQL 16) on the LDBC Social Network Benchmark at scale factors 0.1 and 1, the larger holding 9892 persons, the size of a single online community rather than of a platform. Seven interactive queries mapped to social-analysis tasks, plus PageRank and Louvain, are timed in 3200 executions. No paradigm dominates. The relational engine leads by 3.2–8.1× on the three workloads dominated by aggregation over a two-hop neighbourhood, and the graph engine leads by 1.35–18.0× on the four dominated by the traversal itself; all differences are statistically clear, but this pattern is identified on the same workloads and remains a hypothesis. On the clearest graph-engine win, the ratio of profiling counters (14.9×) tracks the latency ratio (15.3×), suggesting that the gap lies mainly in how much work each plan performs. Query formulation matters more than paradigm: a natural recursive-SQL shortest-path query times out on all 200 executions, while a hop-by-hop rewrite returns in 58.07ms. PageRank is not expressible in standard recursive SQL at all. The ranking survives a worst-case correction for asymmetric connection handling; growth-rate extrapolations do not. An analytical model, not a measured pipeline, indicates how the traversal costs would enter neighbourhood sampling for graph neural networks. A decision framework and a hybrid architecture are proposed.