Multi-Stage NL-to-SQL Pipeline

• Multi-stage NL-to-SQL pipeline is a modular approach that decomposes the conversion of natural language questions into SQL queries into specialized stages.
• The pipeline improves execution accuracy and reliability by isolating tasks like schema introspection, SQL generation, output parsing, and iterative repair.
• Key methods include context augmentation, rule-based verification, and cost-aware model selection that together reduce execution errors and operational costs.

A multi-stage NL-to-SQL pipeline refers to an architectural paradigm that decomposes the transformation of natural-language questions into executable SQL queries via a series of specialized, interacting modules. These pipelines exhibit systematic task partitioning, with each stage dedicated to a narrowly defined subproblem—such as schema retrieval, context adaptation, query generation, validation, repair, or reranking. Their usage is prevalent in recent neural and agentic text-to-SQL (NL2SQL) systems, where stepwise processing yields measurably improved execution accuracy, reliability, and maintainability compared to monolithic, direct generation approaches. This article surveys the design principles, typical modular flows, technical instantiations, and key performance implications of such multi-stage NL-to-SQL architectures, drawing on state-of-the-art systems such as SQL Query Engine, PV-SQL, Blar-SQL, and others (Ijaz, 15 Apr 2026, Tian et al., 19 Apr 2026, Domínguez et al., 2024).

1. Architectural Foundations of Multi-Stage NL-to-SQL Pipelines

Modern multi-stage NL-to-SQL systems follow a sequential architecture that breaks end-to-end translation into dedicated submodules or agents. A canonical flow, as exemplified by SQL Query Engine (Ijaz, 15 Apr 2026), includes:

1. Client Query Reception: Accepts a natural-language question via REST or OpenAI-compatible API endpoints.
2. Schema Introspection & Context Building: Extracts database schema and samples rows (via information_schema.t*, sample queries) and formats them for downstream components.
3. NL-to-SQL Generation: Prompts an LLM (or smaller task-specialized model) to generate both a schema description and an initial SQL candidate, controlling output format with carefully constructed system messages.
4. Multi-Strategy Parsing: Robustly parses the LLM's raw output—supporting formats from JSON blobs to Markdown code-fenced SQL—via a cascade of extraction strategies to maximize resilience against prompt or model idiosyncrasies.
5. Execution & Self-Healing Loop: Executes the SQL on a (typically read-only) database, handling errors or empty results by constructing targeted LLM repair prompts that include detailed diagnostics (e.g., SQLSTATE, traceback), and allowing early-accept or best-result tracking over iterative retries.
6. Result Delivery: Delivers response rows and SQL text to the client in a structured, streamable format.

This modular approach generalizes across leading pipelines, with individual papers emphasizing specific modules—e.g., Blar-SQL's explicit schema linking before generation (Domínguez et al., 2024), PV-SQL's Probing and Verifying agents for ambiguity resolution and constraint enforcement (Tian et al., 19 Apr 2026), or MetaSQL's dedicated generation-then-rank submodules (Fan et al., 2024).

2. Key Stages and Technical Mechanisms

A multi-stage NL-to-SQL pipeline typically features the following key technical modules:

2.1 Schema Introspection and Context Augmentation

Systems execute direct SQL queries against database metadata tables (information_schema.*) to construct a structured schema summary, sometimes sampling up to a fixed number of rows per table to assist downstream models in learning data distributions and type constraints. These summaries are encoded (often as Markdown-formatted DDL) and cached (e.g., in Redis) per user session to minimize redundant overhead and to enable streaming schema context to the client (Ijaz, 15 Apr 2026).

2.2 SQL Generation Modules

Depending on the architecture, SQL query synthesis may be assigned to:

• A large monolithic LLM (common in earlier systems).
• An ensemble of task-specialized models (e.g., Blar-SQL deploys a Llama-2-based model for schema linking and a Code Llama-based model for SQL generation), with each submodel exposed to reduced contextual input (Domínguez et al., 2024).
• A tool-invocation agent that reasons about when and how to call a SQL generator (e.g., ReAct agents in spatio-temporal pipelines (Redd et al., 29 Oct 2025)).

Prompts typically contain system-level instructions, schema snippets, and user questions, with vanilla or augmented input depending on the stage.

2.3 Output Parsing and Normalization

Raw model outputs are parsed by multi-strategy extractors, cycling through direct JSON decoding, balanced-brace scans, code block searches, and finally textual regex or fallback, to derive structured SQL from loosely formatted responses. Alias normalization via model-validated schemas ensures downstream consistency (see _parseResponse algorithm in SQL Query Engine) (Ijaz, 15 Apr 2026).

2.4 Iterative Validation, Repair, and Self-Healing

Sophisticated execution and verification loops execute candidate SQL and, on failure, automatically construct LLM prompts that inject precise error messages and diagnostic codes, prompting the model to attempt targeted fixes (e.g., for syntax, type, or semantic errors). Early-accept logic returns the first correct result with non-empty output; otherwise, pipelines track the largest (“best”) partial result throughout the retry horizon (see pseudocode for SelfHeal) (Ijaz, 15 Apr 2026, Tian et al., 19 Apr 2026).

2.5 Rule-Based and Data-Driven Verification

Pipelines such as PV-SQL extract a checklist of verifiable constraints by pattern-matching trigger keywords in the NL question (“top 3”, “unique”, “percentage”). These are converted into constraint predicates on the SQL, which are checked for satisfaction and iteratively enforced in a loop with LLM-based repairs until all pass or budget is exhausted (Tian et al., 19 Apr 2026).

3. Representative Architectures and System Variants

The following table summarizes key architectural features of selected exemplary systems:

System	Multi-Stage Flow (condensed)	Key Strengths
SQL Query Engine	Introspection → LLM Gen → Multi-parse → Exec/Repair	Self-healing, OpenAI-compat, SSE infra
Blar-SQL	Schema-Link → SQL Gen (decoupled submodels)	Compact, chunked context, open-source
PV-SQL	Probe → Verify (LLM+rules) → Repair loop	Explicit value disambig, rule-based fix
Datalake Agent	Iterative meta retrieval → LLM Gen → Return	Cost-efficient, scalable, agentic loop
Function-Calling LLM	LLM-to-function-mapping → Validated SQL execution	Safety, expert-reviewed SQL, maintain.

Each system embodies the multi-stage idiom but specializes in unique strengths, e.g., safety (function-calling), efficiency (schema chunking, SLM-based flows), or robustness to ambiguous user intent (explicit probe-verification loops).

4. Performance Evaluation and Empirical Impact

Multi-stage pipelines consistently yield measurable improvements in execution accuracy, robustness, and operational metrics:

• Execution Accuracy: For SQL Query Engine, an iterative healing loop increased accuracy on synthetic benchmarks by up to +9.3 percentage points (Llama 4 Scout-17B, 57.3%) and on BIRD by +4.6 pp (GPT-OSS-120B, 49.0%) (Ijaz, 15 Apr 2026).
• Efficiency and Cost: Hybrid SLM/LLM systems (e.g., CESMA (Onyango et al., 25 Feb 2026)) resolve ~67% of queries with low-cost SLMs and trigger expensive LLM fallback only for difficult cases, reducing per-query cost from $0.094 (LLM-only) to$0.0085 (hybrid), a >90% reduction.
• Validation Efficiency: PV-SQL achieves 65.1% execution accuracy and 75.6% valid efficiency score on BIRD, outperforming LLM-only baselines while reducing token usage by >20% (Tian et al., 19 Apr 2026).
• Maintainability and Safety: Function-calling pipelines reduce failed SQL executions by >80%, hallucinated facts by 6.5 pp, and maintenance overhead by 60%, with 85% of function-based answers judged fully correct versus 40% for direct NL-to-SQL (Costa et al., 10 Jun 2025).

5. Contextualization and Future Directions

The multi-stage paradigm is motivated by the limitations of end-to-end, monolithic LLM translation approaches—chiefly, brittleness under schema complexity, lack of determinism, poor error recovery, and operational cost. By modularizing the pipeline, systems localize errors, enable incremental improvement, and allow tailored cost-performance tradeoffs (e.g., LLM fallback only when required).

Active research areas and emerging trends include:

• Agentic Orchestration: Increasing use of ReAct-style agents to plan, decompose, and adapt multistep workflows, especially in challenging domains such as spatio-temporal data (Redd et al., 29 Oct 2025) and large-scale data lakes (Jehle et al., 16 Oct 2025).
• Self-Healing and Repair Loops: The move toward pipelines that can autonomously repair and optimize their SQL generation, utilizing both rule-based and learning-based methods, is likely to continue as models get deployed in safety-critical or production settings.
• Cost-Aware Routing and Model Selection: Systems strategically select between SLMs and LLMs on a per-query basis, balancing accuracy with inference latency and cost (Onyango et al., 25 Feb 2026).
• Constraint Extraction and Checklist Verification: Integration of symbolic pattern-matching as a complement to neural module output, yielding more reliable fulfillment of business logic and user requirements (Tian et al., 19 Apr 2026).
• Schema Scaling and Memory Management: Novel schema chunking and retrieval strategies address the challenge of large and complex databases that exceed model context limits (Domínguez et al., 2024).

6. Challenges and Open Issues

Persistent challenges for multi-stage NL-to-SQL pipelines include:

• Accurate recovery of implicit or ambiguous user intent, especially for compositional or vague queries.
• Generalization across domains or to unseen schemas, where schema linking and chunking strategies must navigate new context representations.
• Robustness and transparency—a nontrivial fraction of failures can still result from limitations in schema understanding, coverage of in-context exemplars, or subtle SQL semantics that are not easily captured by LLMs or pattern rules alone.
• Human-in-the-loop and clarification interaction models for handling irreducibly ambiguous or under-specified questions.

A plausible implication is that further fusion of symbolic, agentic, and neural modeling will continue to drive accuracy, interpretability, and efficiency in NL-to-SQL pipeline architectures.

7. Summary

The multi-stage NL-to-SQL pipeline paradigm embodies the decomposition of the NL-to-SQL task into a structured sequence of specialized, interacting modules. Technical advances—including schema introspection, robust response parsing, iterative repair, and cost-efficient agentic orchestration—have delivered reliable, maintainable solutions with state-of-the-art execution accuracy and strong operational metrics across synthetic and real-world benchmarks (Ijaz, 15 Apr 2026, Tian et al., 19 Apr 2026, Domínguez et al., 2024). This structured, modular approach is now foundational in NL2SQL system design, and is likely to further evolve as agents become more context-aware, cost-sensitive, and user-adaptive.