---
title: 'TS-SQL: Evolving Text-to-SQL & Dialect Evaluation'
url: https://www.emergentmind.com/topics/ts-sql
type: topic
---

# TS-SQL: Evolving Text-to-SQL & Dialect Evaluation

Searching arXiv for recent papers on TS-SQL and related text-to-SQL usage.
Search query: TS-SQL text-to-SQL arXiv
TS-SQL is a context-dependent term in the recent arXiv literature. In most contemporary work it refers to the broader text-to-SQL problem—translating natural language queries into SQL with LLMs, task-specific fine-tuning, agentic orchestration, or reasoning-enhanced decoding—but the same label also appears in discussions of production SQL dialects such as T-SQL/TS-SQL and in database-engine support for time series queries. This suggests that TS-SQL is not a single standardized formalism; rather, it names an overlapping research area spanning natural-language-driven SQL generation, dialect adaptation, production evaluation, and specialized relational execution environments [2410.06011][2604.28049][1805.04265].

## 1. Terminological scope and research landscape

The most explicit large-scale framing appears in "Large Language Model Enhanced Text-to-SQL Generation: A Survey" [2410.06011]. That survey classifies LLM-based text-to-SQL into four groups according to training strategies: prompt engineering, fine-tuning, pre-trained, and Agent. It also identifies cross-lingual and cross-dialect support, including SQL variants like T-SQL, as a future direction, and notes that deployment in T-SQL/TS-SQL environments requires additional evaluation, especially execution and efficiency, using real T-SQL engines [2410.06011].

A second usage appears in production evaluation work. "Agent-Agnostic Evaluation of SQL Accuracy in Production Text-to-SQL Systems" states that STEF normalization absorbs quirks in production SQL common in generators like TS-SQL and explicitly describes suitability across SQL dialects, including TS-SQL and BIRD-SQL [2604.28049]. A third usage appears in database systems research: "Scripting Relational Database Engine Using Transducer" presents transducers as user-coded procedural relational operators for analyses that are difficult to express in SQL, including time series and graph queries, and its detailed summary explicitly situates this in the context of time series (TS-SQL) queries [1805.04265].

| Usage context | Description | Source |
|---|---|---|
| Text-to-SQL / TS-SQL | Natural language queries translated into SQL | [2410.06011] |
| Production dialect context | Production SQL generators and dialect handling such as TS-SQL | [2604.28049] |
| Time series query context | Time series queries executed within a parallel relational database via transducers | [1805.04265] |

This terminological breadth matters because research claims about TS-SQL are often not interchangeable. Results on Spider or BIRD concern natural-language SQL generation; production-native evaluation concerns schema-hidden inference-time settings; dialect adaptation concerns proprietary syntax and procedural constructs; and transducer-based work concerns extending relational engines with procedural operators. A plausible implication is that any encyclopedia treatment of TS-SQL must separate task formulation, system architecture, and execution setting.

## 2. Problem formulation and recurring failure modes

In the dominant text-to-SQL sense, the task is to translate natural language queries into SQL statements so users can interact with databases without knowing SQL syntax [2410.06011]. Recent work emphasizes that this task is not a single monolithic mapping. "DTS-SQL: Decomposed Text-to-SQL with Small Large Language Models" splits it into schema linking and SQL generation, arguing that conventional single-stage supervised fine-tuning forces a small model to identify relevant schema elements and synthesize the SQL simultaneously [2402.01117]. "SQL-to-Schema Enhances Schema Linking in Text-to-SQL" similarly motivates concise schema extraction by observing schema-linking errors, join errors, nested errors, and group-by errors in sophisticated existing methods [2405.09593].

Several papers isolate distinct bottlenecks. "KeyInst: Keyword Instruction for Improving SQL Formulation in Text-to-SQL" argues that a principal challenge is SQL formulation that is not only syntactically correct but also semantically aligned with the natural language input, and attributes this difficulty to the disparity between the NLQ and SQL [2411.00788]. "Knowledge-to-SQL: Enhancing SQL Generation with Data Expert LLM" identifies a different failure mode: some necessary knowledge is not explicitly included in the database schema and user question or has been learned by LLMs, so knowledge-insufficient questions degrade accuracy and robustness [2402.11517]. "PV-SQL: Synergizing Database Probing and Rule-based Verification for Text-to-SQL Agents" sharpens the diagnosis on BIRD, reporting database misinterpretation and question misinterpretation as major bottlenecks [2604.17653].

The survey literature generalizes these observations into a stable taxonomy of research challenges: ambiguity in natural language, schema complexity and diversity, SQL query complexity, data sparsity and generalization, robustness to user errors, efficiency and scalability, and reliability and trustworthiness [2410.06011]. This taxonomy is consistent with more specialized studies. For example, "TrustSQL: Benchmarking Text-to-SQL Reliability with Penalty-Based Scoring" shows that reliability cannot be reduced to raw answer accuracy, because real deployments include infeasible, out-of-domain, and non-SQL questions that require abstention rather than aggressive answer generation [2403.15879].

## 3. Schema grounding, decomposition, and context construction

A central architectural pattern in TS-SQL systems is schema reduction before final SQL generation. DTS-SQL implements this most directly with a two-stage fine-tuning pipeline: a schema-linking model predicts the exact set of tables and columns required by the correct SQL, then a second model generates SQL conditioned only on the relevant subset of the schema [2402.01117]. On Spider test, DTS-SQL with DeepSeek 7B reports 84.4 EX and 73.7 EM, while on Spider dev the two-stage version improves EX from 82.1 to 85.5 and EM from 69.0 to 79.1 relative to single-stage fine-tuning [2402.01117].

"SQL-to-Schema Enhances Schema Linking in Text-to-SQL" adopts a different route: generate an initial SQL with the complete schema, then parse that SQL to extract the concise schema used for final generation [2405.09593]. On Spider, table-recall@4 increases from baseline values such as 0.88, 0.932, and 0.938 to 0.95 for Schema1, 0.978 for Schema2, and 0.981 for Schema3; with CodeLlama-34B, SQL1 reaches 0.748 execution accuracy and SQL3 reaches 0.753, exceeding DIN-SQL, C3, RESDSQL, and the initial SQL0 on the reported setup [2405.09593]. The method therefore treats the model’s own first-pass SQL as a schema selection oracle.

Other systems broaden schema construction beyond symbolic linking. Knowledge-to-SQL introduces a Data Expert LLM, or DELLM, that performs table reading by selecting columns whose semantic similarity to the query exceeds a threshold and then generates expert knowledge conditioned on the query, schema, and selected tables [2402.11517]. DeepEye-SQL uses three parallel schema-linking strategies—Direct, Reversed, and Value-based—and then unions the linked elements and enforces relational closure through foreign key analysis [2510.17586]. MCTS-SQL also begins with a Selector module that filters the database schema to extract the minimal set of relevant tables and columns needed for the query, explicitly to reduce noise, irrelevant field inclusion, computational waste, and input length limitations [2501.16607].

Across these systems, the common principle is that full-schema prompting is typically treated as an upper-context source rather than the optimal immediate input to SQL synthesis. This suggests that TS-SQL research increasingly views schema grounding as a separate optimization problem with its own recall, precision, and failure modes rather than merely a prompt-formatting step.

## 4. Reasoning-centric generation and search-based refinement

A second major trend is the redefinition of SQL generation as an explicit reasoning process. "STaR-SQL: Self-Taught Reasoner for Text-to-SQL" prompts the model to generate detailed chain-of-thought rationales that culminate in the SQL, filters for rationales leading to correct outcomes, and then fine-tunes on those rationale-augmented examples [2502.13550]. It adds an outcome-supervised reward model as a verifier and performs best-of-\(N\) sampling at inference; on Spider dev, STaR-SQL with ORM and best-of-16 reports 86.6% execution accuracy and 72.5% exact match, compared with 55.0% EX for few-shot prompting and 68.6% EX for direct answer-only fine-tuning on the reported model setting [2502.13550].

"Reasoning-SQL: Reinforcement Learning with SQL Tailored Partial Rewards for Reasoning-Enhanced Text-to-SQL" moves from supervised rationale bootstrapping to RL with SQL-specific partial rewards [2503.23157]. Its reward suite includes schema-linking, AI feedback, n-gram similarity, syntax check, execution accuracy, and output format, aggregated as a weighted sum. Using GRPO, the paper reports that all partial rewards together improve Qwen2.5-Coder-7B execution accuracy by +6.77pp over base, versus +4.11pp for supervised fine-tuning, and that the RL-trained 14B model reaches 72.78 EX on BIRD test, outperforming o3-mini by 4% and Gemini-1.5-Pro-002 by 3% on the reported benchmark [2503.23157].

Search-based refinement offers a third reasoning paradigm. "MCTS-SQL: An Effective Framework for Text-to-SQL with Monte Carlo Tree Search" combines a direct generator with an MCTS-Refiner that is invoked when the initial SQL is erroneous or insufficient [2501.16607]. It models a fast-slow thinking approach in which easy cases are handled directly and harder cases undergo iterative critique, execution feedback, self-reward scoring, and UCT-based tree search. On BIRD development, MCTS-SQL with GPT-4o reports 69.40% EX and 66.24% VES, including 51.48% EX on the challenging subset, which the paper states is 3.41% higher than the existing method [2501.16607].

Instructional guidance can also be lighter-weight. KeyInst generates a question analysis and a prioritized list of pivotal SQL keywords such as GROUP BY, HAVING, ORDER BY, LIMIT, EXCEPT, INTERSECT, UNION, and WHERE, and integrates that guidance either through a pipeline or a single-pass strategy [2411.00788]. On StrucQL, KeyInst-FT reports 84.3 overall execution accuracy against 79.5 for DIN-SQL, 82.1 for DAIL-SQL, and 81.0 for SC-SQL; on Spider and Bird, the paper reports consistent gains when KeyInst is added to DIN-SQL, DAIL-SQL, and SC-SQL [2411.00788].

Taken together, these methods show that TS-SQL generation is no longer treated merely as left-to-right decoding over schema-augmented prompts. It is increasingly formulated as rationale induction, reward-shaped exploration, tree search, or structured keyword-conditioned planning.

## 5. Verification, abstention, and production-native evaluation

A defining recent shift is the movement from benchmark accuracy toward reliability, verification, and deployment realism. TrustSQL formalizes reliability as the ability to generate correct SQL for feasible questions and abstain on infeasible ones, and introduces a penalty-based Reliability Score,
$$
\mathit{RS} = \frac{1}{N} \sum_{x}\phi_c(x),
$$
where incorrect answers and wrong attempts on unanswerable questions receive a penalty \(-c\) [2403.15879]. Its main empirical finding is stringent: no method currently achieves positive RS under critical settings, and highly conservative baselines such as abstain-all or ensemble voting can outperform more aggressive generators when penalties are severe [2403.15879]. This directly challenges the common misconception that higher execution accuracy automatically implies safer deployment.

Production evaluation raises an additional problem: benchmark assumptions often fail at inference time. STEF is presented as a schema-agnostic Text-to-SQL Evaluation Framework that operates exclusively on natural language inputs—the original user question, an enriched reformulation, and the generated SQL—without requiring database schema or reference queries [2604.28049]. It extracts semantic specifications from both natural language and SQL, aligns filters, projections, and grouping structure, and produces an interpretable 0 to 100 score via a composite metric combining filter alignment, semantic verdict, leniency for benign extras, and a confidence multiplier [2604.28049]. The framework also treats enriched question quality validation as a first-class evaluation signal and supports prompt-templated rule injection for column mappings, benign filters, and ignored filters [2604.28049]. Its normalization rules explicitly tolerate GROUP BY inference, benign GROUP BY on WHERE-constrained columns, sensible ORDER BY defaults, and large LIMIT safety defaults—patterns the paper identifies as common in production SQL generators like TS-SQL [2604.28049].

Verification has also become an internal component of generation pipelines. PV-SQL combines Probe, which issues targeted probing queries to discover value formats and inter-table semantics, with Verify, which extracts deterministic constraints such as DISTINCT, Top-K, Count, Percent, Extreme, and Temporal requirements and uses them as an executable checklist for iterative repair [2604.17653]. On BIRD, PV-SQL reports 65.12 EX and 75.55 VES, improving on the best baseline E-SQL by 5.0 points in EX and 20.8 points in VES while consuming fewer tokens [2604.17653]. DeepEye-SQL generalizes verification into an SDLC-like orchestration with deterministic checkers for syntax, JOIN logic, ORDER/LIMIT consistency, time format, SELECT ambiguity, null safety, and result meaningfulness, followed by targeted LLM-guided revision [2510.17586].

Error-specific refinement further sharpens this trend. ErrorLLM models text-to-SQL errors explicitly with dedicated error tokens, structural question-schema representations, AST alignment, static detection rules, and semantic detection within a dedicated LLM [2603.03742]. On BIRD dev with GPT-4o SQLs, it reports detection precision 80.12, recall 76.22, and D-F1 78.12, and improves execution accuracy from 55.87% for the backbone to 66.23%, whereas self-correction drops to 55.02% and SQLFixAgent reaches 58.74% on the reported setup [2603.03742]. The paper’s central claim is that detection quality directly determines refinement effectiveness.

## 6. Dialects, enterprise settings, and broader execution contexts

When TS-SQL is interpreted as a production dialectal setting rather than only a benchmark task, dialect support and enterprise context become central. The 2024 survey states that most work targets standard SQL, but methods using MoE architectures or SQL dialect adaptation can be adapted to T-SQL/TS-SQL, and it identifies additional syntax, proprietary functions, and procedural constructs as particular challenges for T-SQL/TS-SQL [2410.06011]. The same survey argues that prompt or agent-based frameworks can integrate database dialect hints or post-generation rewriting tools, and that execution and efficiency must be validated on real T-SQL engines for deployment [2410.06011].

Enterprise-oriented agentic systems pursue this direction directly. "LLM-Based SQL Generation: Prompting, Self-Refinement, and Adaptive Weighted Majority Voting" proposes an SSEV pipeline built on PET-SQL and a multi-agent ReCAPAgent-SQL framework with planning, critique, retrieval, schema linking, action generation, refinement, and validation [2601.17942]. The paper explicitly describes modular RAG, dialect-aware refinement, and robustness for enterprise dialects like TS-SQL, BigQuerySQL, and SnowflakeSQL. It reports execution accuracies of 85.5% on Spider 1.0-Dev, 86.4% on Spider 1.0-Test, and 66.3% on BIRD-Dev for SSEV, and 31% execution accuracy on the first 100 queries of Spider 2.0-Lite for ReCAPAgent-SQL with WMA [2601.17942].

At the database-engine level, the transducer work shows a different extension path. Rather than generating SQL from natural language, it allows users to script a parallel relational database engine with procedural code executed as a user defined relational query operator called a transducer [1805.04265]. The transducer is tightly integrated with parsing, planning, optimization, and execution, can enforce partitioning and ordering, maintains local state across tuples, and is motivated by workloads that are difficult to express in SQL, including time series and graph queries [1805.04265]. In this setting, TS-SQL names not a natural-language interface but a class of stateful analytical queries executed inside the relational engine.

The resulting picture is heterogeneous but coherent. In one branch, TS-SQL denotes text-to-SQL systems whose research frontier now includes schema linking, reasoning, verification, abstention, and production-native monitoring. In another, it denotes deployment on dialects with proprietary syntax and enterprise constraints. In a third, it refers to time series query processing inside relational engines. The strongest unifying theme across these branches is that SQL generation and evaluation are no longer treated as isolated string-generation problems. Current research instead frames TS-SQL as a system problem involving grounding, reasoning, error modeling, verification, efficiency, and operational reliability [2410.06011][2604.28049][2403.15879].

Source: https://www.emergentmind.com/topics/ts-sql