Text-to-SQL in the Era of Large Language Models: A Survey of Reasoning-Centric and Efficiency-Centric Approaches

Abstract

Text-to-SQL translates natural-language questions into executable SQL, enabling non-expert access to relational databases. Despite advances in large language models (LLMs), reliable systems must ground questions in schemas and values, handle large schemas, and preserve semantic correctness. This survey reviews the evolution toward LLM-based and agentic systems through an objective-oriented taxonomy of Reasoning-Centric (RC) and Efficiency-Centric (EC) approaches. RC emphasizes interpretation, grounding, workflow organization, candidate search, and verification; EC emphasizes acquiring, adapting, transferring, and deploying capabilities under identifiable resource or deployment constraints. Assignments reflect a study’s stated objectives and main contribution, not model size, openness, or training strategy alone. We connect three recurring challenges to ten methodological families and provide an evidence-linked inventory of 114 studies with eleven boundary interpretations. Benchmark-aware comparisons retain model, split, metric, and inference-budget distinctions, including twelve illustrative BIRD development configurations from ten studies. Explicit token values are reported by 31 of 114 studies; a further 6 additional approximate, range, or bound disclosures bring the total to 37, including 16 of the 50 representative studies. Heterogeneous scopes, spanning prompt context, pipeline components, dataset totals, and offline generation, limit direct comparison of end-to-end inference consumption. These findings motivate configuration-specific resource reporting. We also discuss security and safety risks and their evaluation implications. The taxonomy, comparisons, and reporting framework support joint analysis of reasoning quality and resource use in systems combining RC and EC mechanisms.

1. Introduction

The rapid advancement of artificial intelligence has accelerated the generation of data at an unprecedented scale and diversity. To efficiently store, manage, and utilize such data, various database management systems (DBMSs) have been developed, including key-value stores and vector databases [1,2,3,4]. Nevertheless, relational database management systems (RDBMSs) remain a fundamental infrastructure for general-purpose data management, and Structured Query Language (SQL) continues to serve as the de facto standard for data retrieval and analysis [5,6]. However, effectively using SQL requires specialized knowledge of database schemas, join conditions, aggregation, and nested query structures. This creates a substantial barrier for non-expert users who wish to directly access and analyze relational data.

As illustrated in Figure 1, Text-to-SQL has been proposed to bridge this gap by translating a natural-language question, together with the corresponding database schema, into an executable SQL query [7,8,9]. It enables users to interact with relational databases without requiring prior knowledge of SQL syntax. However, Text-to-SQL is not merely a sequence generation task. It requires schema understanding, value grounding, join-path inference, the construction of aggregation and nested query structures, and verification of whether the generated query correctly represents the user’s intent. Therefore, modern Text-to-SQL can be viewed as an execution-aware semantic parsing and program synthesis problem [7,9].

Figure 1. Overview of Text-to-SQL.

Over the past few decades, Text-to-SQL research has evolved from rule-based systems to neural semantic parsers and, more recently, approaches based on large language models (LLMs). Early Text-to-SQL systems relied on manually designed lexicons, semantic grammars, query templates, and domain-specific rules. Although effective in restricted environments, these systems were difficult to adapt to diverse linguistic expressions and changing database schemas [7]. Neural semantic parsers subsequently enabled end-to-end learning and introduced structured generation mechanisms based on SQL sketches, abstract syntax trees, intermediate representations, relation-aware schema encoding, and grammar-constrained decoding [10,11,12,13,14,15]. However, their dependence on task-specific training data and limited generalization to unseen schemas and query structures remained major challenges. The emergence of LLMs shifted the research focus from designing specialized SQL parsers toward effectively utilizing general-purpose language models through database context, reasoning procedures, and execution feedback [16,17,18,19].

In modern LLM-based Text-to-SQL systems, however, strong language understanding and reasoning capabilities do not guarantee reliable performance. This difficulty arises from three major challenges. First, a practical system must accurately connect natural-language expressions to database schemas and values by identifying relevant tables and columns, grounding question phrases in database values, and inferring valid join paths before constructing the corresponding SQL query [20,21,22]. Second, real-world databases often contain large schemas, for which including the entire schema in a prompt can introduce substantial context length, inference cost, and irrelevant information, motivating scalable schema retrieval and reduction techniques [23,24,25]. Third, syntactic validity and successful execution do not necessarily guarantee semantic correctness, because an executable SQL query may still produce a result that differs from the user’s intended answer; therefore, execution-guided validation and semantic refinement are often required [26,27,28]. Consequently, recent studies have moved beyond simply adopting larger models and increasingly focus on improving reasoning reliability or achieving competitive performance under limited computational resources.

Considering these aspects, this survey organizes recent LLM-based Text-to-SQL research into Reasoning-Centric (RC) and Efficiency-Centric (EC) approaches. RC approaches defined their main contribution in terms of how a system interprets a question, grounds database evidence, organizes a workflow, explores SQL candidates, or verifies and refines a result. Representative mechanisms include prompt design, demonstration retrieval, schema and value grounding, task decomposition, multi-agent orchestration, candidate search, and execution-guided refinement [18,29,30,31,32,33,34]. Such mechanisms can use proprietary or open models and may combine prompting with supervised fine-tuning or reinforcement learning. Their analytical focus is the reasoning-related process; neither frozen parameters nor increased inference cost is a defining requirement.

EC approaches emphasize acquiring, adapting, transferring, and deploying Text-to-SQL capabilities under identifiable constraints on data, model capacity, context, computation, or deployment. Representative mechanisms include task-specific and parameter-efficient adaptation, synthetic supervision, knowledge transfer, compact or specialized models, schema and context optimization, constrained decoding, and execution-guided post-training [35,36,37,38,39,40,41,42]. Their relevance to efficiency can lie in making a constrained model or deployment setting viable, not only in explicitly reducing a measured cost. However, a study’s use of fine-tuning, synthetic data, reinforcement learning, or an open model is not sufficient by itself for an EC assignment. The connection between its main contribution and the constraint being addressed must be identifiable, while actual resource savings remain an empirical question.

The framework is objective-oriented, not a division between prompting and training. Here, primary optimization focus refers to the main contribution interpreted in light of the authors’ stated objectives and the bottleneck or constraint being addressed. The RC/EC label, the documentary basis for that label, and the reported evidence of accuracy or efficiency are distinct analytical elements. Building on prior analyses of LLM-based Text-to-SQL [9,19], Section 3 connects grounding, large-schema processing, and semantic correctness to the corresponding families and explains how to handle shared mechanisms.

The main contributions of this survey are summarized as follows:

• Source-grounded comparison and challenge–family connections: Table 1 compares four prior surveys by scope, organization, and evaluation coverage, with explicit source versions and section locators. Section 3 connects grounding, large schemas, and semantic correctness to the ten RC/EC families and identifies their distinct interventions in evidence selection, query construction, and validation.
• Explicit assignment principles and cross-family analysis: We distinguish a study’s stated objective, its primary assignment, and the empirical evidence supporting its benefits. We specify the role of objective and method descriptions, the supporting role of relevant ablation or bottleneck analyses, and the distinction between shared mechanisms and ambiguous primary assignments. A complete 114-study inventory links each primary assignment to its objective, methodological role, rationale, model metadata, and source evidence, with eleven explicitly documented boundary interpretations.
• Benchmark-aware quantitative comparison and resource-reporting analysis: Section 6.3 compares twelve BIRD development configurations from ten representative studies with explicit model, metric, budget, and resource boundaries. After source-scope screening, 41 eligible BIRD development-set EX configurations remain from 27 representative studies. Section 6.4 defines common measurement boundaries and examines the availability of token-related resource information across the 114-study corpus and the predefined 50-study representative subset. The analysis distinguishes explicit numerical measurements from approximate values, configured budgets, component-level quantities, and offline resource use, thereby identifying both reporting gaps and barriers to direct cross-study efficiency comparison.

Table 1. Scope, organization, and evaluation coverage of representative Text-to-SQL surveys. Source versions are specified below; unlisted topics are not assumed to be absent.

Survey	Scope and Organization	Evaluation Coverage	Complementary Contribution
Qin et al. [8] (2022)	Single-/multi-turn parsing, encoder–decoder design, and pretraining.	Evaluation metrics and datasets for single-/multi-turn settings.	Relate LLM-era contributions to their optimization focus across parser architectures and interaction settings.
Zhu et al. [9] (2024)	LLM-based prompting, fine-tuning, task-training, and agents.	EM, EX, VES, and TS metrics and benchmark datasets.	Distinguish RC and EC roles when the same training or prompting technique serves different objectives.
Hong et al. [43] (2025)	LLM-based in-context learning and fine-tuning, with paradigm comparisons.	Benchmarks and metrics; computational-efficiency discussion includes costs, tokens, and calls.	Connect constrained capability acquisition and reasoning interventions across training and inference paradigms.
Shi et al. [44] (2025)	LLM prompting stages, fine-tuning, and model characteristics.	Spider 1.0, BIRD, and Spider 2.0; selection of reported leaderboard results and EX-based analysis.	Link assignments and boundary interpretations to study-level evidence while separating accuracy and resource measurement scopes.
This survey (2026)	Two objective-oriented approaches and ten families; 114 primary assignments and 11 boundary interpretations (Section 3, Section 4 and Section 5).	Distinct analysis populations (Table 2); benchmark, diagnostic, and resource-evidence distinctions (Section 6.5).	Separate authors’ objectives, primary assignments, shared mechanisms, and empirical evidence of benefits.

Version and temporal-scope note. Locators refer to the public author versions arXiv:2208.13629v1 (Qin; 29 August 2022), arXiv:2410.06011v1 (Zhu; 8 October 2024), arXiv:2406.08426v8 (Hong; 24 November 2025), and arXiv:2407.15186v5 (Shi; 3 June 2025), not publisher-typeset pagination. Release dates identify the versions examined, not literature-search cutoffs.

Table 1. Scope, organization, and evaluation coverage of representative Text-to-SQL surveys. Source versions are specified below; unlisted topics are not assumed to be absent.

Survey	Scope and Organization	Evaluation Coverage	Complementary Contribution
Qin et al. [8] (2022)	Single-/multi-turn parsing, encoder–decoder design, and pretraining.	Evaluation metrics and datasets for single-/multi-turn settings.	Relate LLM-era contributions to their optimization focus across parser architectures and interaction settings.
Zhu et al. [9] (2024)	LLM-based prompting, fine-tuning, task-training, and agents.	EM, EX, VES, and TS metrics and benchmark datasets.	Distinguish RC and EC roles when the same training or prompting technique serves different objectives.
Hong et al. [43] (2025)	LLM-based in-context learning and fine-tuning, with paradigm comparisons.	Benchmarks and metrics; computational-efficiency discussion includes costs, tokens, and calls.	Connect constrained capability acquisition and reasoning interventions across training and inference paradigms.
Shi et al. [44] (2025)	LLM prompting stages, fine-tuning, and model characteristics.	Spider 1.0, BIRD, and Spider 2.0; selection of reported leaderboard results and EX-based analysis.	Link assignments and boundary interpretations to study-level evidence while separating accuracy and resource measurement scopes.
This survey (2026)	Two objective-oriented approaches and ten families; 114 primary assignments and 11 boundary interpretations (Section 3, Section 4 and Section 5).	Distinct analysis populations (Table 2); benchmark, diagnostic, and resource-evidence distinctions (Section 6.5).	Separate authors’ objectives, primary assignments, shared mechanisms, and empirical evidence of benefits.

Version and temporal-scope note. Locators refer to the public author versions arXiv:2208.13629v1 (Qin; 29 August 2022), arXiv:2410.06011v1 (Zhu; 8 October 2024), arXiv:2406.08426v8 (Hong; 24 November 2025), and arXiv:2407.15186v5 (Shi; 3 June 2025), not publisher-typeset pagination. Release dates identify the versions examined, not literature-search cutoffs.

Table 2. Analysis populations, counting units, and membership rules in the reconciled corpus.

Population	Counting Unit and Size	Membership and Denominator Rule
Bibliography	158 distinct citation keys	All bibliography entries; 44 are outside the taxonomy discussion. Background and dataset references are not automatically counted as methods.
Taxonomy	114 unique studies: 66 RC, 48 EC	Studies cited in Section 4 and Section 5, including empirical, foundational, and annotation-support roles. Cross-family mentions do not increase this count.
Performance-comparison candidates	110 studies; 103 with at least one candidate having an identified split	Numeric final-output SQL-accuracy records under proposed or rerun-baseline configurations. Actual table membership additionally depends on compatible benchmark, metric, subset, configuration, and source evidence.
Token-reporting review	114 study records; 50-study representative subset	Study-level review of token-related disclosures. Explicit numerical values, approximate values/ranges/bounds, and relative/formula/ graph-only evidence remain distinct; measurement scope is retained rather than normalized across studies.

Table 2. Analysis populations, counting units, and membership rules in the reconciled corpus.

Population	Counting Unit and Size	Membership and Denominator Rule
Bibliography	158 distinct citation keys	All bibliography entries; 44 are outside the taxonomy discussion. Background and dataset references are not automatically counted as methods.
Taxonomy	114 unique studies: 66 RC, 48 EC	Studies cited in Section 4 and Section 5, including empirical, foundational, and annotation-support roles. Cross-family mentions do not increase this count.
Performance-comparison candidates	110 studies; 103 with at least one candidate having an identified split	Numeric final-output SQL-accuracy records under proposed or rerun-baseline configurations. Actual table membership additionally depends on compatible benchmark, metric, subset, configuration, and source evidence.
Token-reporting review	114 study records; 50-study representative subset	Study-level review of token-related disclosures. Explicit numerical values, approximate values/ranges/bounds, and relative/formula/ graph-only evidence remain distinct; measurement scope is retained rather than normalized across studies.

The remainder of this paper is organized as follows: Section 2 defines the scope of the survey and reviews the historical development and general workflow of Text-to-SQL. Section 3 presents the objective-oriented taxonomy. Section 4 and Section 5 analyze RC and EC approaches, respectively. Section 6 reviews benchmark datasets and evaluation metrics, compares reported configurations, and examines resource-reporting availability before discussing integrated evaluation. Section 7 examines security and safety, and Section 8 concludes the paper.

2. Background and Overview of Text-to-SQL

Text-to-SQL has evolved from rule- and template-based systems to neural semantic parsers, pretrained language models, and LLM-based systems. With the emergence of LLMs, the research focus has shifted from designing task-specific SQL generation architectures to integrating prompts, database context, reasoning procedures, and execution feedback. This section briefly reviews this evolution and introduces the general workflow and key challenges of modern Text-to-SQL systems.

2.1. Scope, Literature Identification, and Positioning

• Scope and eligibility. This survey provides a focused technical synthesis of Text-to-SQL over relational databases. Its main scope includes LLM-based SQL generation and the supporting processes of schema and value grounding, model adaptation, supervision and knowledge transfer, workflow organization, candidate search, verification, and deployment. Earlier rule-based, neural, and pretrained-model studies are included to explain the historical development of the field and mechanisms inherited by LLM-based systems. The methodological synthesis extends to studies published or publicly released in 2026, including conference and journal articles, workshop papers, and preprints.

Studies are included in the methodological discussion when they propose a relevant approach or empirically analyze a component of these processes. Conference papers, journal articles, workshop papers, and preprints are represented in the corpus. Inclusion is not conditional on the availability of open model weights, a particular model size, or reported resource savings. RC/EC assignment is a separate analytical judgment based on the primary optimization focus, as described in Section 3. General question answering, unstructured document retrieval, table question answering, and generation of non-SQL target languages are outside the core scope, except where they directly inform Text-to-SQL. Intermediate representations used to generate SQL remain within scope.

• Literature identification and publication sources. The relevant literature was identified through Google Scholar using Text-to-SQL as the main search term, together with targeted exploration of ACL Anthology and publication resources associated with VLDB and IEEE. The collection was expanded through citation chaining from previously identified papers. Keyword-based discovery and citation-based expansion were therefore complementary routes for locating relevant studies.

The resulting corpus includes publications from ACL, EMNLP, NAACL, EACL, and COLING, including relevant Findings volumes; database venues such as SIGMOD, Proceedings of the ACM on Management of Data, Proceedings of the VLDB Endowment, and ICDE; and AI and machine learning venues including NeurIPS, ICML, ICLR, and AAAI. Relevant papers from KDD, CIKM, IUI, and PRICAI, as well as associated workshops, journals, and arXiv preprints, are also represented.

• Corpus organization and temporal boundary. The bibliography of the manuscript originally submitted on 30 August 2026 provides the baseline for this revision. During reconciliation on 27 September 2026, the bibliography, manuscript citations, final assignment inventory, and extracted study records were joined by citation key and study identifier, using titles and manuscript locations to resolve correspondence. Repeated citations, including cross-family mentions, were counted once.

The reconciled bibliography contains 158 distinct entries: 114 cited in Section 4 and Section 5, and 44 cited only elsewhere. The 114-study inventory includes methodological studies, empirical analyses, and selected foundational work. The retained records do not document the original search dates, initial retrieval count, duplicate-removal count, or screening and exclusion counts; these historical fields have not been reconstructed. Neither the submission date nor the reconciliation date is a documented last-search date. These counts describe the retained corpus; keyword retrieval and citation chaining may omit relevant publications, so exhaustive coverage is not claimed.

• Positioning relative to prior surveys. Table 1 compares the organizing perspectives of representative surveys and identifies the source sections supporting the comparison. Qin et al. [8] organize single-turn and multi-turn parsing around encoder–decoder designs and pretraining. Zhu et al. [9] distinguish prompting, fine-tuning, task-training, and agent-based methods. Hong et al. [43] organize LLM-based methods primarily around in-context learning and fine-tuning and also analyze methodological trade-offs and computational efficiency. Shi et al. [44] structure prompt engineering by processing stage, alongside fine-tuning, model characteristics, and a comparison of reported benchmark results.

This survey complements these perspectives by connecting methodological contributions to their primary optimization focus across the Text-to-SQL workflow. RC emphasizes question interpretation, grounding, SQL construction, search, and verification. EC emphasizes how task capabilities are learned, transferred, and deployed in relation to identifiable data, model-capacity, context, computational, or deployment constraints. Section 3 specifies how the role of the main contribution determines the primary assignment.

The synthesis connects grounding, large schemas, and semantic correctness to the ten methodological families, and distinguishes an author’s stated objective from the survey’s classification rationale and the empirical evidence supporting a benefit. Final SQL accuracy, intermediate diagnostic results, configured inference budgets, model scale, and measured resource use are treated as distinct forms of evidence. This cross-family perspective complements the organizing approaches of the prior surveys.

• Analysis populations and counting units. Table 2 separates four analysis populations. The linked extraction contains 114 study records, 608 experimental configurations, 1659 model-role records, and 1182 measurement records. These are distinct counting units. Each study has one primary assignment in the final taxonomy inventory, which supplies the assignments used in derived analyses.

The performance availability screen retains numeric EX, EM, TS, or explicitly labelled final-accuracy records for online, full-pipeline SQL output under proposed methods, proposed variants, or rerun baselines. It yields 700 measurements in 546 configurations from 110 studies. Requiring an identified split leaves 561 measurements in 425 configurations from 103 studies. Metric-specific evaluation protocols remain separate. Each comparison specifies its benchmark/version, split, subset, evaluator, model, adaptation, budget, and source version; unknown metadata are retained explicitly. Oracle results, bounds, ablations, annotation-quality results, and non-SQL tasks are recorded separately from this scalar-result pool.

For resource reporting, we separately reviewed token-related disclosures across the 114 studies in the taxonomy inventory and the predefined representative subset. Explicit numerical values are distinguished from approximate values, ranges, or upper bounds, while relative reductions, formulas, and graphical evidence remain separate evidence types. Maximum context or output settings, tokens-per-second throughput, and monetary price per token are not counted as absolute token consumption. The audit describes disclosures in the examined source versions.

Accuracy–resource comparisons additionally retain the configuration and workload pairing, online/offline phase, measured pipeline components, aggregation statistic, and reported hardware and serving conditions. Pairing requires matched workloads and a clearly specified measurement scope. These rules connect the population accounting to the evaluation framework in Section 6.3 and Section 6.4. Throughout the survey, taxonomy labels describe methodological objectives. Cross-study tables and plots summarize heterogeneous reported settings; they do not establish controlled accuracy or efficiency rankings or causal effects of RC/EC membership.

2.2. From Rule-Based Methods to LLM-Based Systems

As illustrated in Figure 2, the evolution of Text-to-SQL can be understood as a sequence of efforts to bridge the ambiguity of natural language and the formal structure of relational databases. Its primary research bottleneck has gradually shifted from manually mapping linguistic expressions to SQL grammar toward data-driven learning, cross-domain generalization, structured generation, and LLM-based reasoning and verification.

Figure 2. Historical evolution of Text-to-SQL research.

• Rule-based NLIDB era. Early Natural Language Interfaces to DataBases relied on manually designed lexicons, semantic grammars, query templates, and domain-specific rules. These systems could provide accurate interpretations in restricted domains with fixed schemas, but they were difficult to extend to unseen expressions, paraphrases, and schema changes. Consequently, substantial manual effort was required whenever the supported domain or query structure changed, limiting the scalability and linguistic coverage of rule-based approaches [7].
• Neural semantic parsing era. The introduction of large question–SQL datasets, particularly WikiSQL, enabled a transition toward data-driven neural semantic parsing. Seq2SQL formulated SQL generation as a sequence prediction problem and employed execution-based reinforcement learning to address the order-insensitivity of SQL conditions [10]. SQLNet instead predicted individual SQL components according to a predefined query sketch, reducing the difficulty of generating an entire query as an unconstrained token sequence [11]. These studies demonstrated that mappings between natural-language questions and SQL structures could be learned through large-scale supervision and established execution accuracy as a central evaluation metric. However, the single-table setting of WikiSQL provided limited coverage of joins, nested queries, and complex compositional structures.
• Cross-domain semantic parsing era. The introduction of cross-domain and multi-table settings shifted the primary challenge from reproducing observed SQL patterns to understanding the structures and relationships of previously unseen databases. SyntaxSQLNet decomposed SQL generation according to its syntactic structure [12], while IRNet combined schema linking with an intermediate representation for complex cross-domain parsing [13]. Subsequent methods explicitly modeled relations among question tokens, tables, columns, and database keys. Representative examples include RAT-SQL and BRIDGE, which advanced relation-aware schema encoding, schema linking, and generalization to unseen databases [14,45]. These developments established Text-to-SQL as a structured cross-domain semantic parsing problem rather than a simple sequence-to-sequence translation task.
• Pretrained language models and structured generation. Pretrained language models further improved contextual representations of natural-language questions and database schemas. At the same time, intermediate representations and constrained generation were introduced to reduce the complex SQL search space. Building on these advances, LGESQL modeled mixed local and non-local relations through a line-graph representation [46], while NatSQL simplified SQL structures that were difficult to align directly with natural-language expressions [47]. PICARD constrained autoregressive decoding by rejecting grammatically invalid tokens  [15]. RASAT and S2SQL integrated relational and syntactic structures into pretrained sequence-to-sequence models [48,49], while RESDSQL separated schema linking from SQL skeleton generation  [50]. Other approaches explored alternative structured-generation mechanisms: SmBoP introduced bottom-up semi-autoregressive parsing, SQLformer generated structured query graphs, and SeaD employed schema-aware denoising  [51,52,53]. Collectively, these methods combined the representation capacity of pretrained models with explicit structural constraints, although they continued to rely heavily on task-specific training data and specialized model designs.

At the boundary between the pretrained-model era and the emerging LLM era, several studies began to move beyond monolithic parser architectures. CatSQL considered practical natural-language-to-SQL deployment  [54], structure- and content-aware prompt learning explored few-shot adaptation [55], and G3R combined graph-guided generation with reranking  [56]. These studies anticipated the modular pipelines and inference-time selection mechanisms that later became common in LLM-based systems.

• LLM-Based and Agentic Systems. The emergence of LLMs shifted the focus of Text-to-SQL research from designing a task-specific parser toward designing an effective interaction protocol around a general-purpose language model. Early empirical work evaluated the zero-shot and few-shot Text-to-SQL capabilities of Codex [16]. C3 introduced a ChatGPT-3.5-Turbo-0301-based zero-shot Text-to-SQL method that combines clear prompting, calibration with hints, and consistent output [17]. Other systems combined demonstration retrieval, task decomposition, schema and value grounding, multi-candidate generation, and execution-based correction [18,19,22]. More recent approaches distribute schema selection, query planning, generation, and validation across multiple agents or use explicit search and database interaction to verify intermediate hypotheses [28,31,33,57,58]. Accordingly, Text-to-SQL has expanded from a problem in which a single model produces an SQL string into a system-level problem involving interactions among LLMs, database contexts, retrieval modules, execution engines, and verification procedures.

The gap between benchmark performance and practical NL2SQL readiness has been explicitly examined [59]. Recent benchmarks and empirical evaluations further show that controlled academic settings do not fully reflect realistic data-analysis environments. Modern systems must handle larger and more complex schemas, ambiguous identifiers, database values, external knowledge, and heterogeneous workflows. As a result, Text-to-SQL research increasingly considers not only query accuracy but also reasoning reliability, computational cost, latency, privacy, and practical deployability  [9,19].

Overall, the historical development of Text-to-SQL reflects a continuous shift in its primary bottlenecks. Early research focused on mapping natural language to SQL grammar, the neural and pretrained-model eras emphasized structured generation and generalization to unseen schemas, and the LLM era has brought schema and value grounding, reasoning orchestration, candidate verification, and deployment efficiency to the forefront. This progression provides the foundation for the general Text-to-SQL workflow and the RC and EC approaches discussed in the following sections.

2.3. General Workflow of LLM-Based Text-to-SQL Systems

Although LLM-based Text-to-SQL systems differ in their model architectures, training strategies, and database interaction mechanisms, most systems follow a common functional workflow. As illustrated in Figure 3, a natural-language question is processed through four main stages: Preprocessing, Schema Linking, SQL Generation, and Verification. The verified SQL query and its execution result constitute the final output. This stage-oriented view identifies where individual techniques intervene, whereas the taxonomy introduced in Section 3 explains whether their primary objective is to improve reasoning reliability or system efficiency [9,19,22].

Figure 3. General workflow of an LLM-based Text-to-SQL system.

• Question. The workflow begins with a natural-language question expressing the user’s information need. The question may contain entities, conditions, aggregation requirements, temporal constraints, or ambiguous expressions that must be interpreted before SQL generation.
• Preprocessing. Preprocessing transforms the question and database information into a model-readable context. Typical operations include normalizing dates, numerical expressions, aliases, and domain-specific terms, as well as serializing schemas using CREATE TABLE statements, structured representations, or natural-language descriptions. Prompt construction, demonstration retrieval, database routing, and compact schema representation may also be applied at this stage [16,19,23,24,29,30,60,61,62]. These techniques reduce irrelevant context and input length, although excessive reduction may remove schema elements required for the final query.
• Schema Linking. Schema Linking connects expressions in the question to relevant tables, columns, database values, and join paths. The system must identify not only semantically related schema elements but also the relational connectivity required to construct an executable query [20,21,22,23,24,63,64]. Recent methods combine schema retrieval, database-content retrieval, extractive schema selection, and question–schema alignment to improve grounding in large or unfamiliar databases [21,22,24,63,64,65,66]. Errors at this stage may propagate to later stages even when the generated SQL is syntactically valid.
• SQL Generation. SQL Generation converts the interpreted question and linked schema context into an executable query. The model may generate SQL directly or use intermediate structures such as decomposed subquestions, query plans, SQL sketches, or partial clauses [18,31,32]. Systems may also generate multiple candidates through different prompts, reasoning paths, agents, or models, and then apply ranking or search to improve candidate coverage [33,34,67,68]. Constrained decoding can further reduce syntactically invalid outputs by restricting generation according to SQL grammar or schema structure [15,69].
• Verification. Verification checks whether the generated SQL is syntactically, structurally, and semantically valid. Static checks can identify malformed syntax, invalid identifiers, and type mismatches, while execution-guided verification can reveal runtime failures or unexpected results [26,27,28,34,70,71]. Because successful execution does not guarantee semantic correctness, systems may also use question–SQL consistency, schema constraints, candidate agreement, test cases, or learned verifiers [27,28,70,72]. When an error is detected, feedback may trigger revised schema linking or SQL regeneration, enabling self-correction and iterative refinement. Execution feedback may also be reused during post-training as a verifiable reward for reinforcement learning or process supervision [41,73,74,75].
• Execution Result. After verification, the system returns the final SQL query and its execution result. Depending on the application, the output may additionally include an explanation, confidence information, selected schema elements, or provenance. This output is not treated as an additional reasoning stage, but as the result of the preceding workflow.

Overall, the workflow provides a stage-oriented view of LLM-based Text-to-SQL systems. RC analyzes how grounding, planning, candidate exploration, and verification are organized, while EC analyzes how capabilities and the surrounding workflow are adapted to data, model-capacity, context, computational, or deployment constraints. A mechanism can contribute to both perspectives. The following taxonomy assigns the primary role by the main contribution rather than by the stage, technique, or an assumed cost outcome.

3. Taxonomy of LLM-Based Text-to-SQL Approaches

As illustrated in Figure 4, the taxonomy comprises two approaches and five families within each. RC comprises Prompt Design and In-Context Reasoning, Schema-Grounded and Data-Grounded Reasoning, Workflow Decomposition and Agentic Orchestration, Candidate Search and Test-Time Scaling, and Verification and Iterative Refinement. EC comprises Model Adaptation and Parameter-Efficient Tuning, Synthetic Supervision and Knowledge Transfer, Compact and Open Models for Efficient Deployment, Context and Inference Efficiency, and Execution-Guided Post-Training and Verifiable Rewards.

Figure 4. Objective-oriented taxonomy of LLM-based Text-to-SQL approaches.

• Assignment principles and evidence. The primary optimization focus is determined from the authors’ stated objectives, the bottleneck or constraint addressed, and the role of the main methodological contribution. RC applies when that contribution principally organizes or strengthens interpretation, grounding, query construction, candidate exploration, or verification. EC applies when the contribution principally concerns acquiring, adapting, transferring, or deploying task capabilities in relation to an identifiable data, model-capacity, context, computational, or deployment constraint. The EC interpretation must be justified from the study rather than inferred from model size, openness, or the use of training alone. The survey’s rationale for an assignment is distinct from the objective explicitly claimed by the original authors.

Objectives and method descriptions provide the assignment basis; relevant ablation or bottleneck analyses offer supporting evidence where available. Ablations are optional, and the largest component-removal accuracy drop alone does not determine the primary objective. The inventory identifies the evidence actually used to justify each assignment.

• Shared mechanisms and boundary cases. A compact model can still be RC when its main contribution is a search or verification procedure. A decomposition method can be EC when its main contribution makes a constrained model viable for the task. Similarly, a trained verifier can serve an RC contribution, while execution-guided post-training can be considered from the EC perspective when its central role is reusable capability development under identifiable model or deployment constraints. These distinctions are consistent with the different roles of decomposition and learned verification discussed in Section 4.3, Section 4.5, and Section 5.3 [18,36,70].

A study may contain both RC and EC mechanisms while having a clear dominant contribution. We distinguish this mechanism overlap from a boundary case, in which more than one primary assignment remains plausible. Secondary mechanisms describe overlap; an alternative primary assignment and an explanation of the choice are needed for a boundary case. Where the objective and method do not support a clear call, the uncertainty should remain visible rather than being resolved by a technique-only rule. The complete inventory in Supplementary Tables S1 and S2 assigns one primary family to each of 114 studies and separates the authors’ objective, the survey’s rationale, secondary mechanisms, and model metadata. It was reconciled against the manuscript and existing extraction records, with selective source checks for conflicting or uncertain cases; it is not an independent re-extraction or an inter-coder reliability study. Appendix A reports the family counts and eleven cases with an explicit alternative primary assignment. These cases document interpretative uncertainty, not a classification error rate. Table 2 defines the inventory and the populations used for performance and resource analyses.

For example, E-SQL is assigned to RC2 because question enrichment primarily strengthens database alignment, whereas BAP-SQL is assigned to EC4 because explicit token and interaction budgets define its optimization target [76,77]. ZAS-SQL transfers reusable failure-derived rules and is assigned to EC2, with RC1 retained as a plausible alternative; rule distillation does not require weight post-training [78]. Conversely, training in STaR-SQL and MARS-SQL supports candidate reasoning and agentic coordination, respectively, so it does not automatically imply an EC assignment [58,79].

• Connection to the motivating challenges. The three challenges in Section 1 complement the objective-oriented taxonomy. Their connections to the families are many-to-many: each challenge can involve several RC and EC families, while a family may address only some challenges. The following discussion explains these methodological roles.

Grounding. From the RC perspective, schema- and data-grounded reasoning investigates how tables, columns, values, and relationships are identified and used as evidence (Section 4.2) [21,63]. From the EC perspective, model adaptation and supervision or knowledge transfer can make grounding-related capabilities reusable (Section 5.1 and Section 5.2), while selective retrieval and context construction address how that evidence fits within practical input and computation constraints (Section 5.4) [23,80,81]. Evidence-selection quality and resource consumption must be assessed separately.

Large schemas. RC analyzes the organization of schema exploration, selection, and subsequent reasoning through grounding and staged or agentic workflows (Section 4.2 and Section 4.3) [22,31]. EC analyzes routing, schema retrieval, and selective context expansion (Section 5.4) [25,61]; the compact-model perspective also considers how limited model capacity is supported by task organization and auxiliary modules (Section 5.3). More exploration can add calls, while excessive reduction can omit required tables or join paths.

Semantic correctness. RC analyzes query decomposition, candidate selection, and execution-based checking or repair (Section 4.3, Section 4.4 and Section 4.5) [18,28,33]. EC analyzes the learning and reuse of generation or correction behavior through adaptation, synthetic supervision, compact-model support, and execution-guided post-training (Section 5.1, Section 5.2 and Section 5.3 and Section 5.5) [36,41,42,82]. Evaluation should distinguish final accuracy, intermediate reasoning quality, and the observed number and cost of repair attempts.

Section 4 and Section 5 develop these connections through mechanisms, representative studies, advantages, and limitations. Section 6.5 distinguishes the evidence needed to assess their accuracy–resource trade-offs.

4. Reasoning-Centric Approaches

Appendix B complements the methodological discussion with a family-level view of selected reported development-set results.

RC approaches focus on organizing and strengthening the processes through which a system interprets a question, grounds database evidence, constructs and selects SQL candidates, and verifies or refines a result. Their main contribution lies in these reasoning-related processes, including prompt and evidence organization, intermediate decisions, tool interaction, search, and feedback. The RC designation does not require frozen model parameters, exclusive reliance on prompting, or increased inference-time computation. Supervised fine-tuning, preference optimization, and reinforcement learning can support an RC contribution when the central mechanism concerns reasoning, search, or verification rather than the acquisition or deployment of capability under resource constraints.

As summarized in Table 3, the five families are Prompt Design and In-Context Reasoning, Schema-Grounded and Data-Grounded Reasoning, Workflow Decomposition and Agentic Orchestration, Candidate Search and Test-Time Scaling, and Verification and Iterative Refinement. Their connections to grounding, large schemas, and semantic correctness are specified in Section 3.

Table 3. Reasoning-Centric families, methodological focuses, and representative studies.

Approach Family	Methodological Focus	Representative Studies
Prompt Design and In-Context Reasoning	Organize task instructions, demonstrations, and intermediate representations to support question interpretation and SQL generation.	[16,19,30,83,84]
Schema-Grounded and Data-Grounded Reasoning	Ground reasoning in database schemas, column relationships, values, and retrieved database content through schema linking and data-aware exploration.	[21,24,57,63,64]
Workflow Decomposition and Agentic Orchestration	Decompose Text-to-SQL into planning, generation, inspection, and correction stages coordinated through specialized modules or agents.	[18,31,32,34,85]
Candidate Search and Test-Time Scaling	Generate and explore multiple SQL candidates through search, ranking, resampling, consensus, and additional inference-time computation.	[33,67,68,86,87]
Verification and Iterative Refinement	Detect and correct SQL errors through execution feedback, consistency checking, semantic validation, and iterative refinement.	[26,27,28,70,71]

An RC assignment is an analytical characterization, not proof that intermediate reasoning is valid or semantic correctness is guaranteed. Final SQL accuracy, stage-level diagnostic evidence, and observed resource use answer different questions. Few-shot and tool-supported mechanisms can be useful when target-database supervision is limited, but this is not a defining condition for every RC study. Additional context, search, or verification may increase tokens, calls, latency, or monetary cost, whereas better organization can avoid redundant work. Both benefits and costs must therefore be interpreted from the reported evaluation rather than inferred from the label.

4.1. Prompt Design and In-Context Reasoning

• Key mechanism. Prompt Design and In-Context Reasoning control the information and reasoning structure presented to an LLM without necessarily modifying its parameters. A prompt may combine task instructions, SQL dialect information, a serialized schema, representative values, output constraints, error-handling rules, and question–SQL demonstrations. The central design problem is therefore to select and organize the most relevant structural and semantic evidence rather than simply increasing prompt length.
• Representative studies. Early evaluations established that zero-shot and few-shot Text-to-SQL performance is highly sensitive to prompt wording, schema representation, and database content [16]. C3 combined clear prompting, calibration, and consistency mechanisms [17], whereas DAIL-SQL treated question representation, demonstration selection, and demonstration organization as separate design decisions [19]. ACT-SQL augmented demonstrations with automatically generated schema-linking chains of thought [30], Selective Demonstrations analyzed example selection in cross-domain settings [88], and PURPLE retrieved examples according to the SQL operators required by the target query [83]. Safe-SQL introduced fine-grained selection and self-augmentation [84], while OpenSearch-SQL combined dynamic few-shot retrieval with Query–CoT–SQL examples [89]. De-semanticized prompting retrieves examples through SQL skeletons rather than database-specific meanings [90]. Tai et al. compare reasoning prompts and subquestion ordering [91], Adapt and Decompose combines reusable database-adapted prompts with least-to-most generation [92], and Divide and Prompt supplies decomposition strategies for clause construction and refinement [93]. PTD-SQL selects targeted demonstrations using question classification [94]. CoE-SQL organizes conversational evidence as SQL edition chains [95], while ROSE uses role-state examples and context anchoring for multi-turn generation [96]. Nan et al. combine similarity–diversity example selection with schema representation and voting; their principal intervention is the evidence organized in the prompt [29].
• Advantages. These methods enable rapid adaptation to a new database or SQL dialect without requiring full task-specific training. Retrieved demonstrations and explicit reasoning instructions can also make the evidence supplied to the model easier to inspect and revise.
• Limitations and evaluation. More context does not necessarily improve performance: complete schemas introduce irrelevant elements, large demonstration sets consume tokens and may contain conflicting patterns, and natural-language similarity does not guarantee SQL-structure similarity. Prompt-based results are also sensitive to contamination, retrieval errors, example ordering, schema serialization, and changes in the underlying model version. Evaluations should therefore report the complete prompt, demonstration source, retrieval model and selection criterion, example count and order, token usage, decoding parameters, and model snapshot under a clearly specified inference budget.

4.2. Schema-Grounded and Data-Grounded Reasoning

• Key mechanism. Schema-Grounded and Data-Grounded Reasoning connects expressions in a natural-language question to concrete database evidence. Schema grounding identifies relevant tables, columns, keys, relationships, and join paths, whereas data grounding links entities, categories, dates, units, and conditions to stored values. Column descriptions, sample rows, external knowledge, and business rules may provide additional evidence when schema names alone are ambiguous.
• Representative studies. RSL-SQL combines forward and backward schema linking with contextual augmentation and voting across alternative schema representations [21]. TCSR-SQL retrieves table content when metadata is insufficient [63], Solid-SQL combines enhanced schema linking with in-context learning [64], and SchemaRAG retrieves a compact question-relevant schema from large catalogs [24]. CHESS connects information retrieval, schema selection, candidate generation, and unit testing [22]; Before Generation, Align It! aligns questions with task-specific information [65]; and Extractive Schema Linking directly predicts relevant schema elements [66]. DCG-SQL retrieves demonstrations using contextual schema-link graphs [97]. Automatic metadata extraction supplies descriptions, links, and examples for downstream generation [98]. PV-SQL probes database constraints to support verification [99], while EG-Refine improves schema semantics through renaming and execution-equivalence checks [100]. E-SQL enriches the question with database-aligned information and candidate predicates; this grounding contribution motivates RC2 even though the paper also analyzes resource use [76]. APEX-SQL validates hypotheses about column semantics through data profiling [101], while SDE-SQL executes SQL probes to iteratively update its database understanding [57].
• Advantages. Grounding mechanisms can reduce hallucinated identifiers and support generalization to unfamiliar or large schemas; the effect depends on the evidence retrieved and its use. Active exploration can additionally reveal value distributions and hidden relationships that cannot be recovered from names or metadata alone.
• Limitations and evaluation. High column precision is insufficient when pruning removes an intermediate table or join key needed to connect the selected relations. Active exploration also adds database calls, latency, access requirements, and privacy risks. Exploratory queries should therefore run in read-only sandboxes with row limits, timeouts, cost guards, access controls, and sensitive-column masking. Evaluations should separately report table and column recall, value-grounding accuracy, join-path connectivity, retained-schema size, final SQL accuracy, and the number of exploratory database calls.

4.3. Workflow Decomposition and Agentic Orchestration

• Key mechanism. Workflow Decomposition and Agentic Orchestration divide Text-to-SQL into explicit stages such as database selection, schema linking, difficulty classification, question decomposition, planning, SQL generation, execution, and correction. By exposing intermediate states instead of concentrating every decision in one generation, these systems allow individual decisions to be inspected and revised.
• Representative studies. DIN-SQL decomposes the task into schema linking, query classification and decomposition, SQL generation, and self-correction, with strategies selected according to query complexity [18]. MAG-SQL uses multiple agents to perform soft schema linking and iteratively construct sub-SQL queries [32], whereas MAC-SQL separates Selector, Decomposer, and Refiner roles [31]. ReFoRCE combines column exploration, format restriction, consensus enforcement, and self-refinement [34]. FlexSQL allows an agent to alternate flexibly between database exploration and SQL execution [85], and MARS-SQL coordinates grounding, generation, and validation agents using database feedback [58]. DEA-SQL filters information and classifies questions before staged generation and correction to manage model attention [102]. Structure-guided generation organizes syntax-tree operations around schema relations [103]. Question-classification-based multi-agent processing chooses the workflow according to the question type [104]. Multi-turn interaction combines retrieval with database feedback during construction [105]. SQLFixAgent coordinates review, diversification, and refinement modules for consistency-enhanced repair [106].
• Advantages. Decomposition exposes intermediate decisions and can support query-specific reasoning strategies or localize an error to a particular stage. Exposing a decision does not by itself establish that the decision is correct. Specialized agents or modules can also use different tools and database views without requiring one model call to solve every subproblem simultaneously.
• Limitations and evaluation. An incorrect schema decision or intermediate plan can propagate through the remaining workflow, and fixed pipelines may overfit to benchmark-specific query patterns. Multiple roles do not guarantee diverse reasoning when the same model and context produce correlated errors. Evaluation should therefore include stage-level ablations against a single-agent baseline, shared- and isolated-context variants, and a tool-only workflow. Studies should report model and tool calls, tokens by stage, latency, failure and recovery rates, and the contribution of each module.

4.4. Candidate Search and Test-Time Scaling

• Key mechanism. Candidate Search and Test-Time Scaling represent uncertainty by generating multiple SQL hypotheses from different prompts, demonstrations, schema subsets, reasoning paths, sampling seeds, or models. Execution results, consensus, learned verifiers, ranking models, and pairwise preference judgments are then used to explore and select from the candidate pool.
• Representative studies. MetaSQL follows a generate-then-rank design [67]. MCS-SQL applies multiple-choice selection to outputs from different prompts [107], whereas PET-SQL reconstructs schema context from preliminary SQL and uses cross-consistency for selection [108]. CHASE-SQL generates diverse reasoning paths and compares them with a preference-optimized selector [68]. Search-oriented systems allocate computation more explicitly: Alpha-SQL applies Monte Carlo Tree Search with a self-supervised reward [33], SQL-o1 expands promising paths using self-reward [109], PExA performs parallel exploration with atomic test cases [86], and R3-SQL combines ranking rewards with selective resampling [110]. XiYan-SQL integrates multiple generation and selection mechanisms [87]. STaR-SQL couples self-taught reasoning with outcome-based selection under additional test-time computation [79]. Complexity-aware SQL search allocates exploration and recombination according to estimated difficulty [111]. LEAF-SQL performs level-wise skeleton exploration and evaluation [112], while residual ensemble optimization develops complementary prompt skills for failures not covered by existing candidates [113]. TriSQL selects generation, refinement, and fallback strategies dynamically [114]. MCTS-SQL uses feedback-driven tree search with a lightweight model; the search procedure motivates RC4, with constrained-model deployment recorded as an alternative EC3 interpretation [115].
• Advantages. Candidate search can recover from a poor first generation, expose alternative join paths or query structures, and provide an oracle upper bound that separates generation quality from selection quality. Adaptive search can also allocate more computation to uncertain or structurally complex questions.
• Limitations and evaluation. The candidate pool must contain a correct query and the selector must identify it; either component can become the bottleneck. Sampling cost often grows linearly or faster, while oracle accuracy may saturate when candidates are correlated. Effective systems therefore need diversity-aware sampling, deduplication, early stopping, uncertainty-based budgets, and cheap-to-expensive cascades. Results should separately report generated and unique candidates, oracle and final accuracy, selector cost, model and database calls, and end-to-end latency.

4.5. Verification and Iterative Refinement

• Key mechanism. Verification and Iterative Refinement detect errors in generated SQL and revise the query before returning a final result. Static parsing and schema constraints expose malformed syntax, invalid identifiers, and type mismatches, while execution reveals runtime errors and unexpected results. Because successful execution does not guarantee semantic correctness, robust verification also considers result plausibility, question–SQL entailment, candidate agreement, unit tests, and learned semantic signals.
• Representative studies. LEVER trains a verifier from generated programs and execution results and uses its score to rerank candidates [70]. Execution-consistency validation compares query behavior across executions [27], whereas execution-guided refinement uses database feedback to diagnose and repair generated SQL [26]. ToolSQL integrates external tools into verification and correction [28]. VET represents intermediate reasoning as verifiable executable traces [72]; ReFoRCE combines self-refinement, consensus enforcement, and column exploration [34]; and ErrorLLM generates model-based diagnoses for SQL errors [71]. Corrective self-consistency uses a trained merge model to correct frequent candidate outputs [116]. DSR-SQL combines progressive execution feedback with coherent context states [117]. SQL-of-Thought applies taxonomy-guided diagnosis and multi-agent repair [118]. MAGIC acquires reusable correction guidelines for query repair; their acquisition also supports an alternative knowledge-transfer interpretation in EC2 [119].
• Advantages. Verification can repair syntax, grounding, and structural mistakes without regenerating the complete pipeline from scratch. Intermediate traces and diagnostic feedback also make failures easier to localize than final-answer-only evaluation.
• Limitations and evaluation. Verification remains vulnerable to semantic errors that pass syntax and execution checks, and iterative refinement can damage an initially correct query through over-correction. Systems should therefore support a no-change option, confidence thresholds, retry limits, semantic-difference checks, rollback, and explicit termination criteria. The broader evaluation issues shared with execution-guided post-training, including spurious execution agreement and the cost of repeated database interaction, are discussed in Section 6.5.

5. Efficiency-Centric Approaches

Appendix B presents selected EC accuracy results; Section 6.4 examines resource reporting.

EC approaches focus on acquiring, adapting, transferring, and deploying Text-to-SQL capabilities in relation to identifiable constraints on data, model capacity, context, computation, or deployment. This perspective covers more than explicit cost minimization: a contribution may make a compact model capable of a difficult task, provide supervision for a data-limited setting, enable model specialization, or organize inference under practical budgets. However, the relevance of these mechanisms to the constraint being addressed must be supported by the study. Training, synthetic data, small model size, and openness are not sufficient classification rules on their own.

As summarized in Table 4, the five families concern model adaptation and parameter-efficient tuning, synthetic supervision and knowledge transfer, compact and open models for deployment, context and inference optimization, and execution-guided post-training with verifiable rewards. Their common analytical concern is how task capabilities are obtained and made usable under constraints. The families need not share a single measured cost objective, and their contributions can also improve accuracy. Their connections to the three motivating challenges are discussed in Section 3.

Table 4. Efficiency-Centric families, methodological focuses, and representative studies.

Approach Family	Methodological Focus	Representative Studies
Model Adaptation and Parameter-Efficient Tuning	Specialize pretrained models and reuse task knowledge through supervised adaptation, multitask learning, and restricted trainable components.	[80,120,121,122,123]
Synthetic Supervision and Knowledge Transfer	Construct and transfer supervision to address data availability, coverage, domain adaptation, and teacher–student capability transfer.	[39,81,82,124,125]
Compact and Open Models for Efficient Deployment	Develop useful Text-to-SQL capabilities in compact or specialized models and support deployment under model-capacity and operational constraints.	[35,36,37,38,126]
Context and Inference Efficiency	Organize context and execution through routing, schema selection, compact representations, constrained decoding, and scheduling under practical budgets.	[23,25,60,61,69]
Execution-Guided Post-Training and Verifiable Rewards	Learn reusable generation and correction behavior from execution-related rewards, with attention paid to capability development under model and deployment constraints.	[41,42,73,74,75]

An EC assignment identifies an efficiency-related optimization focus, not a demonstrated reduction in end-to-end resource use. We distinguish the authors’ stated objective, the survey’s rationale for the assignment, and the measurements reported to support practical benefits. A compact model can still incur substantial retrieval, candidate-generation, or verification overhead; synthetic supervision and post-training can shift work to data generation and training rather than eliminate it. Practical efficiency therefore requires a specified comparison baseline and measurement scope.

Relevant evidence includes data and teacher-model requirements, total and trainable parameters, training computation, context tokens, observed model and database calls, latency, throughput, peak memory, and monetary cost. Model size and configured budgets describe a system but do not substitute for measured end-to-end consumption. Where a paper reports capability or accuracy without corresponding resource measurements, the latter benefit remains unestablished. Section 5.1, Section 5.2, Section 5.3, Section 5.4 and Section 5.5 retain these distinctions when discussing each family.

5.1. Model Adaptation and Parameter-Efficient Tuning

• Key mechanism. Model Adaptation and Parameter-Efficient Tuning specialize a pretrained model using question, schema, and SQL examples so that task knowledge can be reused across queries. Full-parameter adaptation and parameter-efficient tuning differ in which components are updated and stored. Their EC relevance lies in specialization under data, training, or deployment constraints, not in the presence of fine-tuning alone. Reduced dependence on long demonstrations or repeated calls is a possible benefit that must be measured rather than assumed.
• Representative studies. DuBo-SQL presents a fine-tuned variant with concise prompts and a separate retrieval-based variant; EC1 reflects the former, while the latter supports the alternative RC1 interpretation recorded in the appendix [120]. SQLFuse integrates complementary model capabilities and training signals [121], while JOLT-SQL applies joint-loss tuning with confusion-aware noisy-schema sampling [122]. ROUTE uses robust multitask tuning and model collaboration to improve transferability [123]. Schema on the Inside adopts two-phase fine-tuning to internalize schema-related knowledge at scale [80]. Open-SQL combines curated supervision and prompt design to adapt an open model to task and context requirements [127]. FinSQL uses adapters and augmentation to specialize models for private bilingual financial databases [128].
• Advantages. Adaptation can teach schema serialization, SQL dialects, output formats, join structures, and repair behavior once and reuse this knowledge across queries. Parameter-efficient tuning reduces optimizer memory and checkpoint storage and allows multiple domain-specific adapters to share one pretrained model.
• Limitations and evaluation. Training only on perfectly filtered schemas may produce brittle models when retrieval introduces missing or irrelevant elements. Training should include alternative serializations, noisy or incomplete schemas, multiple dialects, and realistic execution errors, potentially with auxiliary objectives for linking, skeleton prediction, error classification, and repair. Adapter routing, versioning, compatibility, teacher inference, synthetic-data generation, quantization, and hyperparameter search can dominate total cost. Studies should report total and trainable parameters, precision, sequence length, batch size, optimizer memory, GPU time, training tokens, and both one-time adaptation cost and per-query inference cost and any measured savings relative to the stated baseline.

5.2. Synthetic Supervision and Knowledge Transfer

• Key mechanism. Synthetic Supervision and Knowledge Transfer construct and reuse task supervision when labeled examples, domain coverage, or target-model capability are limited. The generated material can include databases, SQL queries, questions, reasoning traces, corrections, and demonstrations. Distillation transfers outputs or preferences between models, including from a larger teacher to a smaller student. This family concerns the availability, quality, and transfer of useful supervision; reduced manual labeling does not by itself establish a reduction in total data-generation or training cost.
• Representative studies. Human-free demonstration fusing combines existing demonstrations to increase diversity without additional annotation [129]. OmniSQL constructs synthetic databases and large-scale question–SQL data for multiple open model sizes [124], while Text2SQL-Flow applies a SQL-aware augmentation and validation process [39]. SING-SQL generates in-domain synthetic data from target schemas [81], and human–LLM collaborative annotation combines automated generation with expert review [130]. RetrySQL learns from failed attempts and retry trajectories [82], whereas SQuaD-SQL combines LLM-guided distillation with efficient adaptation [125]. Database exploration creates filtered instructions for adapting linker and generator models [131]. OpenSQL uses intermediate supervision to develop open-model capability with limited data [132]. CoT-enhanced self-training uses self-generated principles as lightweight adaptation supervision [133]. SENSE combines strong-model demonstrations and weak-model preferences for supervised and preference-based adaptation [134]. ZAS-SQL distills reusable rules from failures for data- and context-constrained generation without weight post-training, making knowledge transfer its primary EC2 role [78].
• Advantages. Synthetic supervision can expand structural and linguistic coverage, create examples for rare SQL operators, and adapt models to new schemas or domains with less manual labeling. Curricula can also introduce projections and filters before progressively adding joins, nested queries, set operations, window functions, and dialect-specific features.
• Limitations and evaluation. Parser validity and successful execution do not guarantee that a generated question and SQL query are semantically aligned or non-trivial. Synthetic data may duplicate benchmark patterns, inherit teacher bias, or amplify incorrect SQL conventions. Quality control should examine semantic consistency, result non-triviality, query hardness, schema coverage, linguistic diversity, and structural duplication, with similarity checks against held-out questions, SQL skeletons, and schemas. Studies should report raw and retained example counts, rejection rates, teacher calls, generation cost, structural distribution, and performance on unseen databases and domains.

5.3. Compact and Open Models for Efficient Deployment

• Key mechanism. Compact and Open Models for Efficient Deployment investigates how useful Text-to-SQL capabilities can be obtained with limited model capacity or practical deployment constraints. Task specialization, decomposition, model collaboration, retrieval, and correction can support a smaller generator. Model availability and licensing determine which forms of inspection, adaptation, and local deployment are possible; openness is a descriptive property, not evidence of low cost. The resources used by auxiliary modules, training, and fallback models must be distinguished from the size of the main generator.
• Representative studies. CodeS develops open-source Text-to-SQL models through SQL-oriented incremental pretraining and domain adaptation across model scales [35]. DTS-SQL decomposes the task into stages that can be handled by relatively small language models [36]. DataGPT-SQL-7B provides an open 7B-scale SQL generator [37], and SLM-SQL systematically studies training and inference strategies for small language models [38]. SHARE uses small correction assistants to address repeated expensive correction calls; its selected pipeline still uses a large generator [126]. LitE-SQL combines a lightweight generator with vector-based schema linking and execution-guided correction [40]. MSc-SQL uses joint candidate critique to support small accessible models [135]. Feather-SQL combines compact prompts with divided model roles for constrained inference [136]. LEARNAT-SQL internalizes AST-guided decomposition through training to reduce reliance on inference-time search [137].
• Advantages. Compact models and accessible checkpoints can support locally controlled deployment, adaptation, and reproducibility when their licenses and dependencies permit. Decomposition or auxiliary modules can make tasks feasible for limited-capacity models. A cascade can reserve a stronger model or more extensive search for selected queries, but its average cost and privacy properties depend on the full routing and deployment configuration rather than on the compact generator alone.
• Limitations and evaluation. Smaller models remain vulnerable to long schemas, rare operators, unfamiliar database functions, and compositional reasoning. Retrieval, constrained decoding, demonstrations, and fallback models can mitigate these weaknesses, but their costs must be included in the system total. Comparisons should report total and activated parameters, quantization, context length, decoding configuration, batch size, hardware, KV-cache and peak memory, throughput, latency, and the cost of retrieval and verification. Model and training-data licenses should also be reported because a downloadable checkpoint may still restrict commercial or on-premises use.

5.4. Context and Inference Efficiency

• Key mechanism. Context and Inference Efficiency organizes per-query information and computation through database routing, schema retrieval and pruning, value indexing, compact serialization, constrained decoding, adaptive budgets, and system-level scheduling. The focus is on making the workload manageable under input, search, or serving constraints while preserving necessary evidence. A mechanism that primarily improves grounding or verification can also have an RC role; neither context reduction nor constrained decoding alone establishes lower latency or total cost.
• Representative studies. CRUSH4SQL uses schema hallucination for collective retrieval [60]; DBCopilot routes questions across massive database collections [61]; and Gen-SQL constructs a pseudo-schema to reduce the semantic mismatch between questions and database metadata [62]. LinkAlign supports scalable schema linking in realistic multi-database settings [23], while AutoLink adaptively explores and expands schema context [25]. SchemaGraphSQL uses graph paths to retain connected schema subsets within a controlled context [138]. PICARD is a foundational incremental-parsing method that preserves compatibility with autoregressive models and avoids relying on very large beams; its validity checking also supports an RC5 interpretation, and lower latency is not implied by its EC4 placement [15]. TTD-SQL applies tree-guided token decoding [69]. At the system level, HEXGEN-TEXT2SQL schedules multi-stage workflows across heterogeneous models and hardware [139], whereas BAP-SQL selects database observations under explicit token and interaction budgets [77].
• Advantages. These methods can reduce irrelevant context, avoid some invalid candidates, or allocate work selectively. Routing and adaptive budgets offer ways to reserve more expensive exploration or stronger models for difficult queries. The observed benefit depends on retrieval recall, implementation overhead, and the resulting generation and verification workload; a shorter prompt or narrower search space is not itself a measurement of end-to-end efficiency.
• Limitations and evaluation. Schema pruning creates a precision–recall trade-off: semantic similarity alone may remove an intermediate table, key, grouping column, or implicit relationship. Structural decoding prevents some invalid outputs but cannot guarantee semantic correctness, and scheduling overhead may offset model-level savings. Evaluations should report routing accuracy, table and column recall, join connectivity, retained-schema size, token reduction, model and database calls, time to first token, total latency, throughput, hardware utilization, invalid-query rate, and final execution accuracy under matched resource budgets.

5.5. Execution-Guided Post-Training and Verifiable Rewards

• Key mechanism. Execution-Guided Post-Training uses parsing, execution, result correctness, schema consistency, or intermediate-step quality as learning signals. Reinforcement learning and process supervision can develop reusable generation, reasoning, and correction behavior. The EC perspective concerns the role of this capability development under identifiable model or deployment constraints; the use of execution rewards alone does not determine the primary assignment. Whether learned behavior reduces inference-time search, retries, external verification, or total system cost is a separate empirical question, and a contribution centered on a reasoning or verification procedure can instead have a primary RC role.
• Representative studies. Knowledge-to-SQL incorporates data-expert knowledge into SQL generation and adaptation [140]. Reasoning-SQL defines partial rewards for schema linking, syntax, and semantic reasoning [41]. FINER-SQL trains small language models using fine-grained execution feedback [42], while Reward-SQL combines stepwise execution-aware reasoning with process-supervised rewards [73]. SQL-Trail applies multi-turn reinforcement learning with interleaved execution feedback and an adaptive interaction budget [74], and Every Step Counts studies step-level credit assignment for tool-integrated systems [75]. ReEx-SQL develops execution-aware reasoning while reusing prefixes to control rollout work [141]. ReViSQL combines verified training data with execution-related rewards [142]. EXPO-SQL provides clause-level execution feedback for policy adaptation [143]. Arctic-Text2SQL-R1 develops a reusable training recipe and specialized checkpoint for single-model inference [144].
• Advantages. Execution-related supervision can make successful generation and repair patterns reusable and can support models with limited task capability. Step-level rewards can provide feedback beyond a final-answer signal. These are capability-development mechanisms; their resource implications also depend on training, reward construction, rollout generation, and the inference policy. Accuracy gains or successful learning do not by themselves demonstrate lower deployment cost.
• Limitations and evaluation. The learned policy is bounded by the reliability and coverage of its reward signals. Incomplete rewards may encourage shortcut behavior, unnecessary tool use, or overfitting to the schemas and execution patterns observed during training. Robust objectives should therefore combine complementary signals rather than relying on a single execution result. The cross-cutting questions of semantic reward validity and whether post-training genuinely reduces total system cost are addressed in Section 6.5.

6. Benchmarks, Quantitative Comparisons, and Resource Reporting

Datasets and metrics provide evidence for the questions raised by both RC and EC approaches. Reasoning-oriented mechanisms can be examined through final-task accuracy and diagnostics of grounding, construction, selection, or verification. Efficiency-oriented mechanisms can be examined through capability under the targeted constraint and, where reported, data, training, inference, or deployment requirements. These complementary evaluation questions apply to systems combining both approaches.

Final SQL accuracy can conceal the context, search, and execution budget used to obtain it, while parameter counts or reductions in a single resource can conceal losses in grounding or semantic correctness and costs elsewhere in the pipeline. Both approaches therefore require clearly specified datasets, model configurations, evaluation scopes, and resource conditions. This section reviews established benchmarks and metrics, compares reported configurations, and examines resource-reporting availability under explicit measurement boundaries. The final subsection connects these results to the evaluation of integrated RC and EC systems.

6.1. Benchmark Datasets

Table 5 summarizes representative benchmarks and the capabilities they primarily evaluate. Other datasets provide complementary evaluation settings. CSpider [145] and DuSQL [146] support Chinese Text-to-SQL evaluation, while ADVETA [147] evaluates robustness to adversarial table perturbations. Synthetic relational databases have also been proposed to evaluate robustness beyond fixed benchmark instances [148].

Table 5. Representative Text-to-SQL benchmarks and their primary evaluation focus.

Dataset	Year	Setting	Scale/Origin	Primary Evaluation Focus
WikiSQL [10]	2017	Single-turn, single-table	80,654 question–SQL pairs	Column selection, filtering, aggregation, and large-scale supervised SQL generation
Spider [149]	2018	Cross-domain, multi-table	10,181 questions; 200 databases; 138 domains	Schema linking, join reasoning, complex SQL, and generalization to unseen databases
SParC [150] CoSQL [151]	2019	Cross-domain, multi-turn	Conversational benchmarks constructed over Spider databases	Context-dependent generation, conversational history, ellipsis, and cross-turn consistency
Spider-Realistic [152]	2021	Spider-derived robustness	508 examples over 19 databases	Schema linking when explicit mentions of schema elements are removed from questions
Spider-SYN [153]	2021	Spider-derived robustness	Spider questions with schema-related synonym substitutions	Robustness to lexical variation and implicit question–schema alignment
Spider-DK [154]	2021	Knowledge-augmented Spider	535 Spider-derived question–SQL pairs	Domain knowledge, implicit inference, and knowledge-aware schema and value grounding
Dr. Spider [155]	2023	Systematic robustness	Approximately 15K perturbed examples with 17 perturbation types	Robustness to perturbations in databases, natural-language questions, and SQL structures
BIRD [156]	2023	Cross-domain, large databases	12,751 pairs; 95 databases; 33.4 GB across 37 domains	Database-value grounding, external knowledge, noisy content, and SQL execution efficiency
Spider 2.0 [157]	2025	Enterprise, long-context workflows	600+ real-world tasks using systems such as BigQuery, Snowflake, and PostgreSQL	Large schemas, metadata and documentation retrieval, SQL dialects, and complex analytical workflows

Text-to-SQL benchmarks have evolved together with the primary challenges of the task. Early datasets such as WikiSQL [10] emphasized large-scale supervised learning over relatively simple single-table queries. Spider [149] subsequently established cross-domain and multi-table evaluation, enabling schema linking, join reasoning, and generalization to unseen databases central challenges.

Several benchmarks derived from Spider isolate more specific failure modes. Spider-Realistic [152] reduces explicit lexical correspondence between questions and schema elements, Spider-SYN [153] introduces synonym substitutions, and Spider-DK [154] incorporates domain knowledge that cannot always be recovered from schema names alone. Dr. Spider [155] extends robustness evaluation through systematic perturbations of databases, questions, and SQL queries. In parallel, SParC [150] and CoSQL [151] extend Text-to-SQL to context-dependent and conversational interactions.

More recent benchmarks increasingly reflect challenges encountered in realistic database environments. BIRD [156] emphasizes database-value grounding, external knowledge, and SQL execution efficiency over large databases, while Spider 2.0 [157] targets enterprise-style workflows involving large schemas, multiple SQL dialects, metadata, and database documentation. BIRD-Critic [158] further extends evaluation from SQL generation toward diagnosing and resolving realistic SQL-related problems.

Figure 5 uses the plotting dataset assembled on 27 September 2026 from the corpus extraction described in Section 2.1. Figure 5 includes directly reported absolute numeric values and explicit figure labels for EX, EM, TS, or final accuracy. It retains all recorded splits, including unknown splits, subsets, and result roles, including baseline, oracle, and ablation records; non-SQL tasks (WikiTQ and AIME24) are excluded. Studies are counted once per benchmark and stored study year, and all benchmarks with at least three distinct studies are displayed. This measures the availability of extracted accuracy evidence across the corpus.

Figure 5. Coverage of numeric accuracy evidence in the corpus plotting export of 27 September 2026. Each cell counts distinct studies with EX, EM, TS, or explicitly labelled final-accuracy values for that benchmark and year, across recorded splits, subsets, and result roles. The 14 benchmarks represented by at least three studies are shown. The rightmost column totals each row; a dash denotes no qualifying record. A study may occur in several rows. The 2026 column covers an incomplete calendar year.

6.2. Evaluation Metrics

Text-to-SQL evaluation traditionally focuses on the correctness of the generated SQL. As summarized in Table 6, Exact Match (EM) evaluates structural agreement with a reference SQL query, whereas Execution Accuracy (EX) compares the corresponding execution results. However, EM may penalize semantically equivalent SQL formulations, while EX may accept an incorrect query that coincidentally produces the expected result. Test-suite Accuracy (TS) mitigates this problem by evaluating queries over multiple database instances or test cases. Valid Efficiency Score (VES) further incorporates the execution efficiency of queries that return the correct result. Context-dependent benchmarks may additionally use question- and interaction-level metrics.

Table 6. Representative evaluation metrics for Text-to-SQL systems.

Category	Metric	What It Measures	Main Consideration
SQL-level	Exact Match (EM)	Structural agreement between the predicted and reference SQL	May penalize semantically equivalent SQL with different syntax
Execution-level	Execution Accuracy (EX)	Equality of execution results between predicted and reference SQL	Different queries may coincidentally produce the same result
Semantic	Test-suite Accuracy (TS)	Execution correctness across multiple database instances or test cases	Provides stronger protection against spurious execution matches
Efficiency	Valid Efficiency Score (VES)	Correctness together with the execution efficiency of valid SQL	Focuses on database execution efficiency rather than LLM inference cost
Multi-turn	QM/IM	Correctness of individual turns and complete conversational interactions	Useful for context-dependent benchmarks such as SParC and CoSQL
Stage-level	Diagnostic Metrics	Table/column recall, value grounding, join connectivity, candidate and verification accuracy	Identifies errors hidden by a single end-to-end accuracy score
System-level	Accuracy–Cost	Tokens, model/tool calls, database executions, latency, memory, and cost	Necessary for comparing RC and EC methods under different inference budgets

Figure 6 illustrates the distinction using 20 matched EX–TS configurations from 14 studies on Spider development data. Within these reported configurations, the two metrics differ by 0.6–13.2 percentage points. Each displayed pair was checked against its extracted values and source locations.

Figure 6. Paired execution accuracy (EX) and test-suite accuracy (TS) on Spider 1.0 development data: 20 selected configurations from 14 studies. Each line connects the two metrics for one reported configuration; right-hand values give EX minus TS in percentage points. Rows identify studies by author and year, with model or inference settings shown where applicable. The figure includes results from the cited studies [16,30,35,37,83,91,93,109,123,129,131,134] and two studies by Dai et al.: FineStep (2026a) [75] and ReEx-SQL (2026b) [141].

These end-to-end metrics do not reveal where errors occur within the Text-to-SQL pipeline. Following the workflow in Section 2.3, stage-level evaluation may therefore measure table and column recall, value-grounding accuracy, join-path connectivity, valid-SQL rate, candidate oracle accuracy, selector accuracy, and verification repair rate. Such measurements help distinguish failures in Schema Linking, SQL Generation, and Verification.

Evaluation also requires the computational conditions behind reported accuracy. Section 6.4 defines measurement boundaries for tokens, calls, latency, memory, and monetary cost, and the conditions for pairing these quantities with accuracy. SQL execution and SQL generation costs require separate accounting, as do online inference and offline training or synthetic-data generation.

6.3. Benchmark-Aware Comparison of Reported Results

We compare results at the configuration level, identifying each by study, source version, benchmark, split, model, inference policy, and metric. EM, EX, and TS are retained as distinct measures; fractions are converted to percentages according to the reported unit. Results with an unresolved split are excluded from development-set comparisons.

After source-scope screening, 41 eligible BIRD development-set EX configurations remain from 27 of the 50 representative studies in Table 3 and Table 4. For Table 7, the authors purposively selected one eligible study per family to illustrate a methodological feature, with the reason for each choice stated in the selection notes accompanying Supplementary Table S4. OmniSQL and SLM-SQL were selected to retain same-model, within-study comparisons of sampling policies; SLM-SQL additionally reports completion times. Within each selected study, the displayed configuration is the first eligible record in ascending configuration-ID order, with the paired sampling setting added for OmniSQL and SLM-SQL. This gives twelve configurations from ten studies. Supplementary Table S4 lists the complete eligible set, provides source locations and evidence-status definitions, and marks the twelve displayed configurations.

Table 7. Representative reported execution-accuracy results on the BIRD development set, with model and inference settings. Evidence statuses (Used, Prompt, Unknown) follow the definitions and source locators in Supplementary Table S4.

Family	Study	Model	EX (%)	Inference Setting/Budget
RC1	DAIL-SQL [19]	GPT-4	54.76	Evidence: Used; BIRD-specific inference budget unclear
RC2	RSL-SQL [21]	GPT-4o	67.21	Evidence: Prompt; Two SQL alternatives; correction cap unclear
RC3	MAC-SQL [31]	GPT-4-32k	59.39	Evidence: Used; 2-shot; at most 3 error-correction rounds
RC4	CHASE-SQL [68]	Gemini 1.5 Pro; Flash selector	73.01	Evidence: Used; Three generation strategies; pairwise selection
RC5	ErrorLLM [71]	GPT-4o; CodeS-7B verifier	66.23	Evidence: Unknown; Selective localization and refinement
EC1	JOLT-SQL [122]	Qwen2.5-Coder-7B	60.40	Evidence: Unknown; Greedy decoding; schema-linking threshold 0.05
EC2	OmniSQL [124]	OmniSQL-7B	63.90	Evidence: Unknown; Greedy decoding; temperature 0
EC2	OmniSQL [124]	OmniSQL-7B	66.10	Evidence: Unknown; 8 samples; temperature 0.8; execution voting
EC3	SLM-SQL [38]	Qwen2.5-Coder-1.5B	64.84	Evidence: Prompt; 16 generation + 8 revision samples
EC3	SLM-SQL [38]	Qwen2.5-Coder-1.5B	67.08	Evidence: Prompt; 64 generation + 8 revision samples
EC4	AutoLink [25]	DeepSeek-V3; BGE retriever	66.36	Evidence: Unknown; 5 SQL candidates; up to 10 agent turns and 5 correction turns
EC5	FineStep-4B [75]	Qwen3-4B-Instruct	68.51	Evidence: Prompt; SC@8; temperature 1.0

• What can be compared. Within the extracted OmniSQL configurations, EX changes from 63.9% under greedy decoding to 66.1% under eight-sample voting, a difference of 2.2 percentage points [124]. This establishes a reported accuracy–sampling-budget trade-off, but not a runtime or monetary-cost ratio. For SLM-SQL, increasing generation samples from 16 to 64, while retaining eight revision samples, changes EX from 64.84% to 67.08%; the corresponding reported development-set completion times are 0.83 and 2.68 h [38]. Its reported US$0.22 and US$0.70 figures are estimates based on an author-specified GPU rental price. Section 6.4 defines the measurement scopes and conditions for linking accuracy to resource use.
• Descriptive result distributions.Figure 7 presents development-set EX results using the same corpus plotting export of 27 September 2026 as Figure 5, with reconciled taxonomy assignments. For this analysis, we apply a narrower inclusion rule and source-scope exclusions to the saved records. Eligible records have a known study year and a directly reported or explicitly figure-labelled absolute EX value for a proposed full system, evaluated online on a full development subset of one of the five displayed benchmarks. The two empirical Spider prompt-evaluation configurations of Rajkumar et al. [16] are additionally included. Test or unknown splits, other metrics, partial subsets, baseline reruns, oracle results, and ablations are excluded. Specifically, two Reward-SQL BIRD configurations are excluded because the source describes a filtered development set with unresolved filtering criteria and size [73]; the DIN-SQL Spider result of 74.2% is excluded because its EX versus TS interpretation differs across the examined sources [18,30]. No replacement score is substituted, and DIN-SQL’s BIRD result remains eligible. The resulting 230 configurations from 86 studies are plotted individually, preserving multiple settings per study. Years use the extraction’s study-year metadata, and small horizontal offsets separate overlapping points. Appendix B restricts this plotting selection to the representative studies in Table 3 and Table 4 and the Spider 1.0 and BIRD benchmarks.
  

  Figure 7. Development-set execution accuracy from the corpus plotting export of 27 September 2026 after the source-scope exclusions described in Section 6.3. Points show 230 qualifying configurations from 86 studies, including the two empirical Spider configurations. Panel labels give configuration and distinct-study counts separately. Colors and markers follow the reconciled RC/EC assignments. Horizontal offsets separate overlapping points within the stored study year.

6.4. Resource Measurement Boundaries and Reporting Availability

• Measurement scope. Resource measurements are meaningful only when their scope is explicitly defined. Online accounting begins with an incoming request and ends at the declared system output, but individual studies may include different subsets of schema retrieval, generation, candidate selection, verification, tool interaction, and database execution. Offline accounting instead covers activities such as synthetic-data generation, teacher-model use, training, and infrastructure construction. These quantities should not be combined without an explicit amortization model. Accordingly, resource values are directly comparable only when they refer to compatible models, benchmarks, splits, workloads, pipeline boundaries, and inference settings. A configured candidate count, context-length limit, or parameter count describes a system configuration but does not by itself measure actual resource consumption. Likewise, a component-level token count or latency value should not be interpreted as an end-to-end system cost.
• Availability of token-related resource reporting. Although resource reporting encompasses multiple dimensions, as summarized in Table 8, our quantitative tally is limited to token-related disclosures. We do not systematically quantify the reporting frequency of model/tool calls, latency, or monetary and end-to-end costs across RC and EC studies. To assess how often token-related information is available, we separately reviewed token-related disclosures across the 114 studies in the taxonomy inventory. Explicit numerical token values were identified in 31 studies. Of these, 19 are assigned to RC and 12 to EC. An additional six studies reported approximate values, ranges, or upper bounds, resulting in 37 studies with some form of absolute token-related quantity, comprising 24 RC and 13 EC studies. Among the 50 representative studies listed in Table 3 and Table 4, 16 provide such absolute token-related information (9 RC and 7 EC). A further six studies provide only relative reductions, formulas, or graphical evidence and are therefore not counted as absolute token disclosures. Supplementary Table S3 identifies the studies included in each reporting category and records their token quantities, measurement scopes, and source locations. The reported token quantities span per-query use, dataset totals, prompt or context length, output tokens only, individual pipeline stages, and offline data generation. For example, RSL-SQL reports dataset-level input and output token totals, ErrorLLM reports token use for detection and refinement while excluding initial SQL generation, and Text2SQL-Flow reports tokens used for offline training-data generation. These scope differences limit direct comparison of end-to-end inference consumption.
  Table 8. Common measurement boundaries for resource reporting.

  Dimension	Reported Quantity	Required Boundary and Conditions
  Tokens and calls	Input/output tokens; model/DB calls; per-query statistics	Include or explicitly exclude retries, selectors, verifiers, tools, and cached inputs. Separate observed consumption from configured limits.
  Latency	Per-query distribution; whole-workload completion time	Specify endpoint, included stages, hardware, precision, batch size, concurrency, warmup, and timeout handling. Do not equate makespan with isolated-query latency.
  Memory and model	Measured peak memory; total/active/trainable parameters	Separate training and inference, include relevant auxiliary models, and distinguish capacity or parameter-based estimates from observed peaks.
  Offline resources	Training/data-generation time, GPU-hours, teacher calls/tokens, and reported cost	State the stage, run count, hardware, data scope, and any excluded teacher, filtering, retrieval, or infrastructure work.
  Monetary cost	Reported bill or author-estimated amount, with currency and workload	Identify price date/rate, API or rental basis, and component versus full-service coverage. A tariff alone is not a measured expenditure.
  Reproducibility	Model/checkpoint, access conditions, license, software and hardware	Distinguish open weights from verified use conditions. Preserve unspecified information rather than inferring it from a model name.

• Implications for reporting. Future evaluations should report resource quantities together with the configuration to which they apply, using the boundaries in Table 8. Token reporting should distinguish input and output, per-query statistics and dataset totals, online and offline phases, and full-pipeline and component consumption. Reports should identify the benchmark, split, model, decoding or sampling policy, candidate budget, and included stages. Repeated model, tool, or database calls should be counted alongside token and latency measurements. Accuracy and resource values should only be paired when they correspond to the same model, benchmark, split, workload, and inference configuration. Resource values for external baselines, offline stages, or other workloads must be identified separately. For multi-candidate, iterative, or agentic systems, each reported accuracy should be linked to the resources consumed under that setting, rather than combining a low-cost setting with the paper’s highest accuracy.

6.5. Rethinking Evaluation for Integrated RC and EC Systems

• Shared correctness risks. Execution is used by both RC verification and EC post-training, but successful execution is not equivalent to semantic correctness. A spurious query may return the expected result by coincidence, while empty results, nondeterministic functions, or incomplete test data may provide misleading verification or reward signals. Refinement introduces an additional risk: a system can repair an incorrect query, leave it unchanged, or damage an initially correct query. Integrated evaluation should therefore supplement single-instance execution accuracy with test suites, semantic checks, schema and type constraints, and explicit repair-transition statistics for repaired, damaged, unchanged, and non-convergent cases.
• Shared resource accounting. RC techniques may increase inference cost through demonstrations, exploration, candidate generation, verification, and repeated database execution. EC techniques may reduce these costs at deployment while transferring them to synthetic-data generation, teacher-model calls, post-training, retrieval infrastructure, or external support modules. A compact generator may likewise depend on an expensive surrounding pipeline. Comparisons should therefore measure the complete lifecycle and pipeline under matched constraints, including training data and computation, model and reward-model size, context tokens, model and tool calls, candidates, database executions, memory, latency, throughput, and monetary cost. Database interactions should be performed in protected read-only environments with row, time, resource, and access-control limits.
• Integrated benchmark design. Practical systems increasingly combine both directions: a compact model may process simple queries using a reduced schema and escalate uncertain cases to database exploration, candidate search, or a stronger verifier. Future datasets should therefore annotate or systematically vary the factors that determine both reasoning demand and resource demand, including schema scale, query complexity, ambiguity, value grounding, external knowledge, SQL dialect, and deployment conditions. The same task set should be evaluated under controlled tiers of context, candidate, tool-call, and database-execution budgets rather than allowing each system to use an incomparable resource configuration.
• Integrated metrics and reporting. EM, EX, TS, and VES should be accompanied by stage-level measures for grounding, routing, candidate coverage and selection, verification, and recovery. System-level reporting should then characterize the accuracy–resource relationship through an accuracy–cost curve, constrained accuracy at fixed budgets, the minimum cost required to reach a target accuracy, or a Pareto frontier. These views reveal whether a method improves capability, reduces resource use, or merely shifts cost to another stage, and thus provide a more appropriate basis for comparing integrated RC and EC systems [9,19,157].

7. Security and Safety of LLM-Based Database Interfaces

LLM-based Text-to-SQL systems connect natural-language requests to executable database operations. Their deployment therefore requires safeguards beyond semantic correctness and computational efficiency. A valid query may expose restricted information, modify persistent data, or impose excessive database load. These concerns apply to both RC and EC approaches and motivate the following considerations.

• Threats and attack surfaces. User requests and lower-trust context, including schema descriptions, database contents, and execution feedback, can influence subsequent SQL generation. Prompt injection may exploit these inputs to redirect model behavior, while jailbreaking attempts to bypass model-level restrictions. SQL-Trail explicitly discusses injection through database context, disclosure through intermediate observations, and destructive or resource-intensive queries [74]. MSc-SQL and ReFoRCE likewise identify risks associated with automatic execution and unauthorized extraction [34,135]. Stored-content prompt injection should be distinguished from traditional second-order SQL injection, where stored attacker-controlled values later enter unsafe SQL construction. Applications should consider both paths where relevant, rather than treating successful SQL execution as evidence of safe behavior.
• Defenses and execution safeguards. Protection should combine application policies with database-enforced restrictions. Generated queries should be checked before execution, and database permissions should reflect the authenticated user’s authorized scope. SDE-SQL emphasizes access control, sandboxing, and human oversight even under local deployment [57]. Read-only credentials can reduce unintended modifications, but additional controls are needed for restricted data access and expensive queries. BAP-SQL illustrates how execution and observation budgets can be enforced independently of the model’s planning [77]. Such controls provide useful components for safer deployment, although resource-budget compliance alone does not establish resistance to adversarial attacks.
• Privacy and safety alignment. Local deployment can reduce the transmission of sensitive context to external providers, but does not ensure authorized query generation. Intermediate results and logs also require protection. VET distinguishes detailed auditing traces from a restricted disclosure mode, illustrating the trade-off between observability and privacy [72]. At the model level, training for SQL correctness should be distinguished from learning security policies. Similarly, syntactic constraints such as those used by PICARD do not establish that a query respects access rights [15]. Policy-aware supervision, adversarial training, and appropriate refusal behavior are therefore relevant research directions whose effectiveness requires dedicated evaluation. They should complement independently enforced permissions and execution controls.
• Evaluation and implications for RC/EC. Security evaluation should specify attacker capabilities, database permissions, and attack budgets. It should distinguish harmful SQL generation from actual policy violations after application and database controls. Relevant outcomes include unauthorized disclosure, forbidden state changes, resource-limit violations, and end-to-end attack success. These outcomes should be reported alongside clean execution accuracy, false rejection of legitimate requests, and defense overhead. Testing should include indirect and multi-turn attacks in isolated environments. RC exploration may increase exposure through repeated observations and executions, while EC deployment choices may change external-data exposure and the resources available for verification. Security should therefore be evaluated alongside reasoning quality and efficiency, rather than inferred from either taxonomy assignment. The cited studies motivate these requirements, but do not collectively establish comprehensive resistance to prompt injection or jailbreaking.

8. Conclusions

Text-to-SQL has evolved from rule-based natural-language interfaces and task-specific neural semantic parsers into LLM-based systems that coordinate prompting, database grounding, structured generation, candidate exploration, and execution feedback. Accordingly, modern Text-to-SQL should not be viewed merely as the generation of an SQL string from a natural-language question. It is an end-to-end process in which database context construction, schema and value linking, SQL generation, and verification jointly determine the correctness and practical usability of the final query.

This survey organized recent LLM-based Text-to-SQL research by primary optimization focus while retaining the RC–EC framework and its ten methodological families. RC emphasizes the organization of interpretation, grounding, query construction, search, and verification. EC emphasizes the acquisition, adaptation, transfer, and deployment of capabilities under identifiable data, model-capacity, context, computational, or deployment constraints. The authors’ stated objectives and the main methodological contribution provide the basis for these assignments.

Many recent systems combine RC and EC mechanisms through schema retrieval, structured reasoning, candidate generation, execution feedback, model adaptation, and efficient deployment within the same pipeline. Such combinations reveal an important system-level tension: additional reasoning and verification can improve accuracy and robustness but may increase token consumption, model calls, database executions, latency, and operational cost. Conversely, aggressive context reduction or model compression may improve efficiency while reducing schema recall or reasoning capacity. Evaluating a Text-to-SQL system therefore requires both correctness measures and an explicit account of the resources used to obtain them. Benchmark version, dataset split, schema context, model configuration, candidate budget, and execution budget should be reported together rather than reducing evaluation to a single accuracy score.

The quantitative synthesis illustrates within-study accuracy–sampling trade-offs on BIRD. Explicit token values are reported by 31 of the 114 studies, increasing to 37 when approximate values, ranges, and bounds are included. Measurement scopes vary across per-query consumption, dataset totals, context size, individual pipeline stages, and offline processing. These findings motivate explicit measurement boundaries and configuration-level linkage between accuracy and resource use.

Future Text-to-SQL systems are expected to increasingly integrate RC and EC techniques adaptively. Instead of applying the same reasoning pipeline to every question, a system may allocate its model capacity, schema-context size, candidate budget, verification depth, and number of database interactions according to query difficulty and uncertainty. Simple questions could follow a compact and low-cost path, while ambiguous or structurally complex questions could invoke additional grounding, search, or verification. Progress toward this integration will require evaluation protocols that jointly measure semantic reliability and end-to-end system cost under large, dynamic, and realistic database environments. The proposed taxonomy provides a framework for analyzing this convergence and for designing Text-to-SQL systems that are not only accurate, but also efficient, reproducible, and practically deployable.

• Limitations of this survey. This survey focuses on LLM-based Text-to-SQL methods over relational databases rather than providing exhaustive coverage of all natural-language interfaces to structured data. Table question answering and the generation of non-SQL formal languages are outside the core scope, except where they directly inform Text-to-SQL. Coverage is bounded by the scope and corpus boundaries described in Section 2.1; relevant studies may have been missed or become available after the corpus was assembled. In addition, assigning studies according to their primary optimization focus involves interpretive judgment, particularly when methods combine RC and EC mechanisms. Primary RC/EC assignments therefore reflect the survey’s interpretation of the dominant focus and do not imply that the underlying mechanisms are mutually exclusive. Cross-study comparisons are also constrained by differences in benchmark versions, dataset splits, base models, and inference budgets. This survey synthesizes reported findings rather than independently re-evaluating the surveyed methods under a common experimental setting. The resource-reporting analysis is also limited by the information available in the examined paper versions. Failure to identify a qualifying resource value does not establish that no such information exists in another version or Supplementary Materials. Moreover, the identified token-related quantities differ in scope and aggregation, and many cannot be paired directly with a reported accuracy result. Where end-to-end resource measurements or implementation details are unavailable, conclusions about relative efficiency remain limited.