Preprint. Under review.
DW-Bench: Benchmarking LLMs on Data Warehouse Graph Topology Reasoning
arXiv:2604.18964v1 [cs.AI] 21 Apr 2026
Ahmed G.A.H Ahmed Innosol / Bahçeşehir University [email protected] C. Okan Sakar Department of Computer Engineering, Bahcesehir University, Turkey [email protected]
Abstract Text-to-SQL benchmarks test whether a model can write the right query. They do not test whether it understands the schema it queries. A data warehouse schema is a graph: tables linked by foreign keys, rows anchored to source records through ETL lineage. Tracing that structure (finding join paths, detecting disconnected silos, propagating impact through lineage chains) is routine data engineering, but no existing benchmark measures it. We present DW-Bench, a benchmark for graph topology reasoning over data warehouse schemas. It contains 1,046 questions (13 subtypes, three difficulty levels, five datasets, 262 tables). We run six baselines, from flat context injection to tool-calling and code execution, against Gemini 2.5 Flash, DeepSeek-V3, and Qwen2.5-72B. Tool-augmented baselines reach 87–90% micro-EM; static methods top out at 63–81%. The gap narrows on easy subtypes and widens on hard ones: no method exceeds 61% while the oracle clears ≥99.5%. That gap is a reasoning problem. Obfuscating table names drops static baselines 9–32 pp; tool-use loses under 4 pp. Code, data, and per-question results: https://github.com/AJamal27891/dw-bench.
1
Introduction
Text-to-SQL has made rapid progress: state-of-the-art LLMs now approach or match human-level accuracy on Spider [21] and BIRD [13], which measure a model’s capacity to translate a naturallanguage question into a SQL query. However, even the latest benchmarks like Spider 2.0 [11] show that enterprise-scale SQLworkflows remain largely unsolved (best models ∼17–21%). Data warehouses, on the other hand, present a different kind of problem. A data engineer maintaining an enterprise warehouse does not primarily write SQL. Instead, they trace graph structure: lineage edges, foreign key (FK) paths, disconnected schema silos. Common questions include: • “If the Person table changes, which downstream tables are affected through data lineage?” (impact analysis) • “Which tables form disconnected silos in our schema graph?” (connectivity analysis) • “What is the shortest FK path between two tables?” (routing) Answering these questions demands breadth-first search (BFS), connected-component detection, and multi-hop path enumeration. No existing benchmark assesses LLMs on these capabilities over real-world data warehouse schemas with heterogeneous edge semantics. 1
Preprint. Under review.
Our evaluation reveals three principal findings: (i) all models achieve near-perfect scores on singlehop structural queries but drop 30–40 percentage points on compositional multi-hop tasks, exposing a systematic structural reasoning ceiling; (ii) Tool-Use prompting closes the gap on topologyenumeration subtypes but fails on compositional lineage-impact queries that require chaining multiple graph algorithms; and (iii) obfuscating table names degrades performance by up to 32 pp on lineage tasks, confirming that models partially rely on lexical cues rather than genuine graph traversal. Our contributions are summarized as follows: 1. DW-Bench: 1,046 schema-level questions across 5 data warehouse schemas (4 real-world, 1 synthetic), covering 3 categories (lineage impact, schema routing, silo detection), 13 subtypes, and 3 difficulty levels. 2. Six baselines (Flat Text, Vector-RAG, Graph-Augmented, Tool-Use, ReAct-Code, Oracle), tested with Gemini 2.5 Flash, DeepSeek-V3, and Qwen2.5-72B. 3. An obfuscation protocol that randomizes table names, enabling controlled evaluation of memorization versus genuine topology understanding. 4. Syn-Logistics: A synthetic dataset with n ≥ 20 per subtype. It exposes a model-dependent structural gap: Gemini scores 93–100% on hop_count/count, while DeepSeek drops to 27–48% on the same subtypes. 5. Open-source release of all datasets, evaluation code, and baseline implementations.
2
Related Work
Text-to-SQL Benchmarks. Spider [21] established the standard benchmark setting, with 10,181 questions spanning 200 databases. BIRD [13] introduced noisier and more realistic schemas, while Spider 2.0 [11] scaled the setting toward enterprise-style schemas. ScienceBenchmark focuses on scientific databases. RobuT [23] evaluates cell-level and row-level reasoning. All of these benchmarks target query generation or cell-level reasoning; none explicitly evaluate structural understanding. Schema Understanding. BEAVER [1] evaluates LLMs on database knowledge including schema matching and entity resolution, but does not evaluate graph topology reasoning. LLM-FK [18] evaluates FK discovery, a single-hop structural task complementary to DW-Bench’s multi-hop topology reasoning. Graph Reasoning in LLMs. NLGraph [20] and GraphQA [4] evaluate LLMs on synthetic graph problems (connectivity, shortest path). GraCoRe [22] taxonomizes graph reasoning; GraphArena [17] benchmarks graph algorithms at scale. However, none of these use real database schemas, and none combine FK and lineage edge types. Graph-Centric Agents and GNN Hybrids. Think-on-Graph [16] interleaves LLM reasoning with knowledge graph exploration; Graph Chain-of-Thought [9] augments prompts with graph-derived reasoning chains. G-Retriever [7] uses GNN encoders to retrieve the graph context for LLM QA. Retrieval-augmented generation [12] (RAG) and hierarchical GraphRAG [3] address knowledgeintensive tasks but do not specifically target schema topology. Recent work on tool-based graph reasoning agents (e.g., GraphWalk) explicitly studies scale and iteration budgets for compositional navigation, while structural-reward training frameworks (e.g., STRuCT-LLM) offer alternative methods to scaffold compositional reasoning. DW-Bench does not compare against these advanced graph-agent frameworks; following the precedent of Spider and BIRD, we evaluate standardized, zero-shot baselines to establish a lower bound. These methods are natural next steps: the Oracle upper bound (≥99.5% EM) quantifies exactly how much room remains for hybrid architectures combining tools with learned graph representations.
2
Preprint. Under review.
Table 1: DW-Bench dataset statistics. “Silos” = disconnected components in the combined FK+lineage graph. Dataset
Domain
Tbl
FK
Lin.
Qs
Silos
AdventureWorks TPC-DS TPC-DI OMOP CDM Syn-Logistics
Retail Analytics ETL Health Supply
102 24 35 37 64
136 70 29 74 96
39 0 21 21 35
208 127 181 158 372
11 1 2 3 5
262
405
116
1046
—
Total
Positioning. DW-Bench uniquely combines: (1) real-world schemas from industry standards, (2) heterogeneous edge types (FK + lineage), (3) practical question types from data engineering workflows, and (4) obfuscation for contamination control.
3
DW-Bench: Benchmark Design
3.1
Datasets
We select five datasets shown in Table 1 representing diverse data warehouse topologies: AdventureWorks is a Microsoft reference data warehouse with 102 tables spanning OLTP and DW layers, connected by 136 FK edges and 39 lineage (derived_from) edges. Its dual-layer structure makes it ideal for lineage impact questions. TPC-DS is the industry standard analytics benchmark with a star schema of 24 tables and 70 FK edges. Its single connected component and absence of lineage edges tests pure FK-based reasoning. TPC-DI is the data integration benchmark with 35 tables modeling an ETL pipeline from staging to warehouse, with 21 lineage edges representing the transformation flow. OMOP CDM (Observational Medical Outcomes Partnership Common Data Model) [8] is a healthcare standard with 37 tables, 74 FK edges, and 21 lineage edges across 3 connected components (clinical data, vocabulary tables, and metadata). Syn-Logistics is our own synthetic supply-chain schema: 64 tables, 5 connected components (carrier, procurement, healthcare, finance, HR). We built it to fix a statistical-power problem in the real-world corpus: every subtype gets n ≥ 20 questions. Table names come from a domain dictionary so obfuscation does not collapse semantics. 3.2
Schema Graph Representation
Each dataset is represented as a heterogeneous graph G = (V, E f k ∪ Elin ), where V denotes the set of table nodes, E f k denotes the set of foreign-key edges, and Elin denotes the set of data-lineage edges, using PyTorch Geometric [5] HeteroData. Each node represents a table and is associated with six structural features: in-degree, out-degree, normalized degree, lineage degree, betweenness centrality, and PageRank. Edges are typed as either fk_to (foreign key) or derived_from (data lineage). Lineage edges form a strict DAG (directed acyclic graph): each derived_from edge points from a downstream DW table to its upstream source, with no cycles or self-references. All traversal algorithms respect edge typing: FK queries use only fk_to edges, lineage queries use only derived_from, and combined_impact queries compose both types sequentially. FK edges are treated as directed (parent→child) for path and hop-count queries (join_path, hop_count, direct_fk) and as undirected for connectivity queries (membership, connected, isolation, count, full_enum).Lineage edges are always directed (downstream→upstream), following the derived_from convention defined above. Foreign keys are treated as bidirectional (undirected) explicitly for connectivity and silo-detection subtypes, as an FK implies an inherent structural relationship that can be traversed logically in either direction (e.g., from a parent lookup table to child fact rows, or vice versa).
3
Preprint. Under review.
Category
Subtype
Diff.
Description
#Qs
Lin.
forward reverse multi_source transitive combined_impact
Easy Easy Med. Hard Hard
Direct lineage targets Source tables for DW table Tables with 3+ sources Multi-hop lineage chains Lineage + FK dependents
72 71 49 33 69
Rt.
direct_fk join_path hop_count
Easy Med. Med.
FK adjacency check FK shortest path Path length
100 342 124
Silo
Table 2: Question taxonomy. Difficulty is assigned based on the number of reasoning hops and edge types required.
count isolation connected membership full_enum.
Easy Med. Med. Hard Hard
Number of components Is table X isolated? Are X and Y connected? Which component has X? List all tables in silo
30 60 29 38 29
For path-based questions, we validate alternative valid shortest paths against the FK adjacency matrix, ensuring EM is robust to tie-breaking. 3.3
Question Generation
Questions are generated deterministically from the graph structure using standard graph algorithms (BFS, connected component detection) implemented with NetworkX [6], ensuring ground-truth answers are provably correct. We define three categories with 13 subtypes as shown in Table 2. Difficulty assignment. Difficulty labels are assigned a priori based on structural complexity, following the precedent of Spider [21] (which uses SQL AST depth) and BIRD [13]. Easy subtypes require a single graph lookup (one hop, one edge type). Medium subtypes require multi-hop traversal within a single edge type. Hard subtypes require either multi-hop transitive closure or composition across both FK and lineage edge types. These labels are fixed properties of the question structure, independent of any model’s empirical performance. 3.4
Obfuscation Protocol
To distinguish genuine topology-based reasoning from reliance on surface lexical cues and schemaname memorization, we generate an obfuscated variant for each dataset. Table names are replaced with random identifiers (Table_A, Table_B, etc.) using a deterministic mapping. This prevents models from exploiting semantic signals in names such as Customer or Invoice to infer relationships without genuine structural reasoning. Questions and answers are updated accordingly with word-boundary-aware replacement to avoid corrupting natural language phrases (e.g., the word “relationship” in “foreign key relationship” is preserved).
4
Baselines
Six baselines are evaluated under a shared prompt with different context injection strategies, all in the zero-shot setting. Each paradigm receives the form of context that is natural to its architecture, rather than being constrained to token-budget parity, since the goal is to compare reasoning paradigms rather than token counts. The baseline methods are briefly summarized below. Flat Text (FT). Dump the whole schema (tables, columns, FKs, lineage) as plain text. This mirrors what a developer does when pasting data definition language (DDL) into a long-context model.
4
Preprint. Under review.
Table 3: Main results (EM % ± 95% CI, pooled across 5 datasets, 2000 bootstrap resamples). Bold = best non-oracle. Model
FT
VR
GA
TU
RC
Gem.
Micro Macro
76.6 77.0
72.9 72.4
75.4 77.1
89.3 86.6
81.4 69.9
DS
Micro Macro
69.5 68.2
71.0 62.4
76.8 69.5
90.4 88.4
79.4 71.6
Qw.
Micro Macro
63.2 64.8
69.5 62.8
80.9 77.5
87.5 82.5
64.6 62.2
Oracle
99.5 / 99.8 / 100.0
Vector-RAG (VR). Embed schema elements with Sentence-BERT [15], retrieve k=15 chunks via FAISS [10], inject as context. Graph-Augmented (GA). Extract a 3-hop BFS neighborhood around the tables mentioned in the question. For global questions with no anchor tables (“how many components?”), supply the full graph instead. Tool-Use (TU). Provide the model with nine graph reasoning tools: shortest_path, connected_ components, get_component_of, get_fk_neighbors, get_lineage_forward, get_lineage_ reverse, transitive_lineage, check_fk_adjacency, list_tables. A maximum of three tool calls is allowed per question. ReAct-Code (RC). The model writes and runs Python/NetworkX code in a sandboxed REPL, up to 5 rounds. More flexible than TU and serves as a budget ablation (5 code rounds vs. TU’s 3 tool calls). Oracle. Gold algorithmic outputs are injected into the prompt. This establishes the upper bound.
5
Experiments
5.1
Setup
We evaluate with Gemini 2.5 Flash [19] (closed frontier), DeepSeek-V3 [2] (671B MoE, openweight), and Qwen2.5-72B [14] (72B dense, open-weight), using greedy decoding (τ=0) for deterministic reproducibility. We report pooled Micro-EM (overall exact match) and Macro-EM (mean of per-subtype EM, weighting all 13 subtypes equally). For list-typed topology tasks (e.g., connected component membership), we apply target-node normalization (stripping the queried table from both prediction and gold prior to scoring) ensuring models are not penalized for harmless self-inclusion. An Oracle baseline injects gold algorithmic outputs, establishing an upper bound (≥99.5% EM across all three models; the residual gap reflects minor formatting, not reasoning failures). 5.2
Main Results
Results are shown in Table 3 and the main findings are summarized below: Finding 1: Agentic baselines dominate. TU tops the ranking at 87–90% micro-EM, roughly 7–14 pp ahead of the best static baseline. RC also clears static methods through code generation. Finding 2: Triviality Illusion. FT looks competitive at 76.6% micro-EM, but the illusion comes from join_path (33% of questions) inflating the average. Macro-EM, which weights subtypes equally, puts GA ahead of FT among static methods; all still trail TU by >8 pp (Appendix Figure 3).
5
Preprint. Under review.
Table 4: EM (%) by difficulty. TU achieves near-perfect easy scores but plateaus on hard questions alongside static baselines. Model
Diff.
FT
VR
GA
TU
RC
Gem.
Easy Med. Hard
82.7 78.9 56.1
82.5 73.0 46.5
82.2 76.3 55.6
99.6 90.3 59.9
90.4 78.7 60.9
DS
Easy Med. Hard
82.7 65.3 40.1
84.4 65.3 43.6
87.1 76.0 50.0
98.0 97.0 60.4
88.8 76.3 58.9
Qw.
Easy Med. Hard
77.4 57.7 33.2
84.0 63.0 40.1
86.6 90.7 51.0
96.1 92.0 57.4
72.2 64.7 44.1
99.0 / 99.5 / 100.0