SPORTSQL: Live Sports Data Query System

• SPORTSQL is a modular, interactive system that translates natural language queries into executable SQL for real-time Premier League analytics using Fantasy data.
• It employs a hybrid model that combines persistent storage with just-in-time, query-dependent table materialization to maintain live, temporally indexed data.
• The system integrates LLM-driven entity grounding, schema-based SQL generation, and integrated visualization to deliver practical insights in sports analytics.

SPORTSQL is a modular, interactive system for natural language querying and visualization of dynamic sports data, developed around English Premier League analytics built on Fantasy Premier League data. Its central operation is the translation of ordinary-language questions into executable SQL over a live, temporally indexed database, with outputs rendered either as direct answers, tables, or charts. The system is paired with the Dynamic Sport Question Answering benchmark, DSQABench, which contains 1,700+ queries annotated with SQL programs, gold answers, and database snapshots, thereby situating SPORTSQL at the intersection of text-to-SQL, live database reasoning, and sports analytics (Martinez et al., 23 Aug 2025).

1. Task formulation and conceptual scope

SPORTSQL is designed for what its authors call “dynamic sports question answering”: a setting in which player statistics, team standings, fixtures, and per-match records change continuously, making static question-answering assumptions inadequate. The motivating examples include longitudinal trend queries, ranking queries, home-versus-away comparisons, and thresholded player filters such as “List forwards with at least ten goals and five assists.” In this formulation, the challenge is not merely semantic parsing, but semantic parsing against a database whose relevant content may change between query times (Martinez et al., 23 Aug 2025).

A common misconception is to treat SPORTSQL as a conventional chatbot over sports facts. The system is explicitly not positioned that way. Its answer path is grounded in SQL execution over a relational backend rather than unconstrained generation, and its database is described as “live” and “temporally indexed.” This distinguishes it from earlier sports QA settings such as LiveQA, which contains 117k multiple-choice questions over more than 1,670 NBA games and emphasizes timeline understanding, event tracking, and mathematical computation over play-by-play live broadcast, but does not use executable SQL or a relational execution target (Liu et al., 2020).

2. Modular architecture and execution path

The SPORTSQL pipeline is modular. At the storage layer, it streams structured sports data from the public Fantasy Premier League API into a MariaDB backend. The backend is refreshed periodically through cron jobs and can also be augmented at query time when a request references data that are not already materialized. This gives the system a hybrid execution model rather than a fixed warehouse model (Martinez et al., 23 Aug 2025).

The storage strategy separates persistent “query-agnostic” tables from transient “query-dependent” tables. Persistent tables hold core entities such as players, teams, and fixtures. Query-dependent tables capture more specific views, including a player’s past games, historical season-by-season record, or next fixtures. Instead of storing all such relations permanently, SPORTSQL fetches them from FPL on demand, materializes them in memory for the current query, executes SQL, and then discards them. The paper states that this design keeps the persistent database under 5GB while preserving access to fine-grained, current analytics (Martinez et al., 23 Aug 2025).

The end-to-end execution path is: natural language query, entity grounding, schema-conditioned SQL generation, SQL execution on live or just-in-time materialized data, and conversion of the result into a dataframe. If the generated SQL names a table absent from persistent storage, the execution layer triggers a just-in-time API request, loads the resulting relation in memory, reruns the query, and discards the temporary table afterward. This architecture makes SPORTSQL neither a pure text-to-SQL benchmark system nor a static dashboard frontend; it is an execution-oriented interface over evolving sports data (Martinez et al., 23 Aug 2025).

3. Data model, temporal indexing, and schema semantics

SPORTSQL’s database is described as live and temporally indexed, but the paper does not provide a formal temporal logic or mathematical definition of the index. Its implementation-level meaning is concrete: the system preserves time-sensitive information such as season history, week-by-week evolution, recent-past slices, and future fixtures, and it supports queries about trends over the last five seasons, current standings this season, and recent player form by combining persistently refreshed tables with just-in-time retrieval from FPL (Martinez et al., 23 Aug 2025).

The schema is only partially enumerated in prose, but several relations are identified explicitly. Persistent storage includes at least players, teams, and fixtures. Dynamic or player-specific tables include player_past, player_history, and player_future. The appendix-level examples indicate that the players table includes fields such as web_name and goals_scored, that the teams table includes attributes such as team_name, position, points, and strength, and that player_history contains season-level records including season_name, total_points, minutes, goals_scored, assists, and clean_sheet (Martinez et al., 23 Aug 2025).

The system’s prompting layer also exposes schema semantics that function as a lightweight ontology. The prompt guidance states, for example, that the players table should generally be preferred for individual statistics, that “team position” maps to league_rank, that “form” is defined as the 30-day average of match points, and that strength ranges from 1 to 5. These are not generic text-to-SQL annotations; they are domain-specific semantic constraints injected to stabilize query generation over a sports schema whose meanings are partly conventional rather than lexically transparent (Martinez et al., 23 Aug 2025).

4. Natural-language grounding, symbolic reasoning, and visualization

After query submission, SPORTSQL performs entity recognition and grounding through a prompt-guided LLM stage. Sports queries frequently contain nicknames, abbreviations, alternate spellings, or informal references, and the system does not rely on exact string matching. Instead, the LLM infers likely canonical names and produces a case-insensitive wildcard SQL query over curated reference tables such as players and teams. The database returns candidate rows and corresponding primary keys, and those IDs become the grounded entities used downstream. This means the LLM is not trusted to know live data values; it is used to formulate symbolic lookups that are then resolved against the current database (Martinez et al., 23 Aug 2025).

SQL generation is schema-driven rather than data-driven. The SQL-generation model receives the user question, the resolved primary keys from grounding, and the database schema, but not the full table contents. The prompt includes table-selection hints, synonym mappings, cautions about columns, formulas for derived fields, and scale explanations. The paper gives concrete examples: penalty saves are almost always only meaningful for goalkeepers, “form” is the 30-day average of match points, and “team position” corresponds to league_rank. This prompt design is intended to reduce common semantic failures without requiring direct access to the live cell values (Martinez et al., 23 Aug 2025).

SPORTSQL’s visualization layer is integral rather than ornamental. Queries may explicitly ask for plots, graphs, or trends, but the system may also infer that a chart is preferable if the output dataframe has structures such as multi-season time series or long categorical rankings. A second code-generating LLM then emits self-contained Python code using Matplotlib and Seaborn. The chart vocabulary includes line plots for trends, bar charts for rankings, horizontal bar charts, timelines, and a color scatterplot example. A validation layer requires that the visualization code reference the exact dataframe returned by SQL “byte-for-byte”; otherwise, the system triggers automatic re-querying or correction. This is a guard against the plotting model inventing or modifying data (Martinez et al., 23 Aug 2025).

In relation to adjacent systems, SPORTSQL is close to SoccerRAG in that both answer natural-language sports questions by generating executable SQL over a relational database. The divergence is architectural and operational. SoccerRAG works over an augmented SoccerNet-derived SQLite database, inserts an extractor-validator stage before SQL generation, and uses FAISS retrieval over human-crafted SQL exemplars with $K=2$ for few-shot prompting, whereas SPORTSQL emphasizes schema-only SQL generation over live FPL data, just-in-time table materialization, and an integrated visualization stage (Strand et al., 2024).

5. DSQABench and empirical behavior

DSQABench is SPORTSQL’s evaluation benchmark for dynamic sports querying. It contains 1,793 questions generated from 180 base templates, each rephrased three ways and instantiated with real-world values. The benchmark combines semantically controlled template generation with manually crafted harder questions, and every item is paired with a manually authored gold SQL query, a gold answer, and the relevant database snapshot at execution time. This snapshotting is central in a live-data setting because the same question may have a different answer on a different date (Martinez et al., 23 Aug 2025).

The answer distribution is heterogeneous. Of the 1,793 questions, 1,395 have scalar outputs such as strings or numbers, while 398 require tabular outputs. A further 398 questions specifically involve dynamic, player-specific tables obtained through just-in-time API access: 270 use player_past, 72 use player_history, and 54 use player_future. DSQABench therefore measures not only text-to-SQL generation, but also performance under schema-only prompting, dynamic table access, temporal reproducibility, and multiple output modalities (Martinez et al., 23 Aug 2025).

Evaluation is type-aware. For string answers, the paper uses exact match. For tables, it uses TabEval, which converts table outputs into atomic natural-language statements and scores pairwise entailment using RoBERTa-MNLI, reporting precision as “Correctness,” recall as “Completeness,” and F1 as “Overall.” With GPT-4o and Gemini-2.0 Flash, both run at temperature 0.1 and max token length 2048, scalar performance reaches 80.48 exact match for GPT-4o and 76.23 for Gemini-2.0. On table questions, Gemini records Correctness 0.64, Completeness 0.76, and Overall 0.69, while GPT-4o records 0.70, 0.81, and 0.75 respectively (Martinez et al., 23 Aug 2025).

Primitive-level analysis shows that the benchmark is far from solved. The system categorizes questions into six SQL primitives: Retrieve, Filter, Calculate, Compare, Order, and Manipulate. Single-primitive queries are easiest: Retrieve reaches 100%, and Order reaches 97.6%. Combined Calculate + Compare also performs strongly at 96.3%. Performance then degrades sharply with compositionality: Retrieve + Filter + Calculate falls to 22.3%, Compare + Order to 30.3%, and Manipulate-heavy join queries to 15.4%. Accuracy by number of primitives starts at 93% for one-step queries, drops to 67% with two primitives, and stabilizes near 50% beyond three. The paper’s interpretation is that aggregation, complex filtering, and table restructuring remain major bottlenecks, and that row-level predicate selection is harder than retrieving the correct columns or broad information (Martinez et al., 23 Aug 2025).

6. Limitations, broader significance, and research trajectories

The paper is explicit about SPORTSQL’s limitations. Top-$k$ ranked queries using LIMIT can omit tied results because of default ordering behavior. The system is English-only. Context-length limitations constrain how much real-time metadata can be included in prompts, including transfers or lineup changes. The implementation is tightly focused on the EPL and would require domain-specific schema remapping, and perhaps fine-tuning, to transfer to other leagues or sports. The error analysis further indicates that aggregation, complex filtering, and joins are weak points; multi-primitive compositional reasoning remains difficult; and row-level selection is harder than broad semantic retrieval (Martinez et al., 23 Aug 2025).

Even with those constraints, SPORTSQL is significant because it occupies a middle ground between static text-to-SQL and unstructured sports QA. It preserves grounding and interpretability through SQL execution over a live relational backend, while also exposing tabular and visual answers. This makes it a template for question answering in evolving structured domains rather than only a soccer-specific application. The authors explicitly identify future work in more advanced query types, comparative and multi-turn analyses across players, teams, and seasons, multilingual LLMs, retrieval-augmented generation, adaptive components, and extension to other domains such as finance, healthcare, basketball, or American soccer (Martinez et al., 23 Aug 2025).

A broader research implication emerges when SPORTSQL is placed alongside adjacent sports data systems. SoccerRAG shows a practical natural-language interface over a SoccerNet-derived archive but remains centered on a structured archive rather than a live database (Strand et al., 2024). “Simulating Tracking Data to Advance Sports Analytics Research” provides 3,000 simulated soccer games of 3,000 timesteps each from Google Research Football, stored in a schema analogous to real tracking feeds and augmented with extracted passes, receptions, shots, turnovers, interceptions, and stints, addressing the scarcity of public high-resolution tracking data for continuous invasion sports (Radke et al., 25 Mar 2025). SportsSUSHI shows that long-term player identity can be stabilized by hierarchical graph tracking with jersey number, team ID, and field coordinates (Koshkina et al., 28 Feb 2025). WASB-SBDT contributes a widely applicable baseline for frame-level ball location across soccer, tennis, badminton, volleyball, and basketball (Tarashima et al., 2023). Graph-based game-state modeling demonstrates that permutation-invariant player-interaction graphs can support prediction and “what if” analysis in American football and esports (Xenopoulos et al., 2022). CricBench, finally, provides a multilingual cricket Text-to-SQL benchmark over 1,169 IPL matches and shows that even the best Context-Aware setting reaches only 50.6% Data Match, indicating that general benchmark strength does not transfer cleanly to specialized sports SQL (Devraj et al., 26 Dec 2025).

Taken together, these results suggest a broader interpretation of SPORTSQL as an architectural pattern rather than only a single EPL system. A plausible implication is that future SPORTSQL-like systems could move from live fantasy statistics toward continuous tracking, video-derived events, graph-structured states, and multilingual domain ontologies, provided that grounding, schema control, and answer-level evaluation remain as strict as they are in the current design.