MARS-SQL: Dual Approaches to Text-to-SQL

• MARS-SQL is a term applied to two distinct SQL-agent systems: one uses semantic-layer mediation for enterprise NL2SQL, and the other employs multi-agent RL for interactive query generation.
• The semantic-layer-mediated system leverages a deterministic SMQ-to-SQL compiler and curated business abstractions, achieving 94.15% execution accuracy on the Spider2-snow benchmark.
• The RL-based system utilizes a ReAct-style Think-Act-Observe loop with specialized agents, attaining 77.84%–89.75% EX on BIRD-dev and Spider-test benchmarks.

Searching arXiv for papers on MARS-SQL and closely related SQL-agent systems. MARS-SQL is a designation used in recent arXiv literature for two distinct systems that address difficult Text-to-SQL and enterprise NL2SQL settings through staged, execution-aware reasoning rather than single-pass SQL generation. One system is a semantic-layer-mediated agent for heterogeneous enterprise databases: it reasons over a curated semantic layer via a Semantic Model Query (SMQ), relies on deterministic SMQ-to-SQL compilation, and reports 94.15% execution accuracy on the 547-task Spider2-snow benchmark (Kim et al., 30 Jun 2026). The other is a multi-agent reinforcement-learning framework with a Grounding Agent, Generation Agent, and Validation Agent, where the Generation Agent follows a multi-turn ReAct-style Think-Act-Observe loop against a live database and the full system reports 77.84% EX on BIRD-dev and 89.75% EX on Spider-test (Yang et al., 2 Nov 2025). The common thread is decomposition of grounding, SQL construction, and verification, but the two systems differ materially in representation, supervision, and deployment assumptions.

1. Name usage and problem formulation

Recent arXiv usage applies the name MARS-SQL to two related but non-identical problem settings. The semantic-layer-mediated system targets enterprise NL2SQL over heterogeneous databases, where schemas may contain hundreds of physical tables with cryptic column names, heterogeneous SQL dialects, and complex analytical workloads requiring nested aggregations, temporal reasoning, and multi-table joins. The multi-agent RL system targets difficult Text-to-SQL more broadly, emphasizing large noisy schemas, compositional queries, and the need for environmental interaction and self-correction (Kim et al., 30 Jun 2026, Yang et al., 2 Nov 2025).

In both settings, the motivating claim is that raw-schema, one-shot prompting is brittle. The semantic-layer-mediated variant decomposes the task into grounding and composition: the agent first identifies business entities, measures, dimensions, and joins through a curated semantic layer, then assembles the final SQL using verified physical column names and join logic revealed by a deterministic compiler. The RL variant decomposes the task into grounding, generation, and validation, treating SQL writing as an interactive decision process rather than a single translation (Kim et al., 30 Jun 2026, Yang et al., 2 Nov 2025).

A recurring misconception is that MARS-SQL denotes a single canonical architecture. The literature instead uses the name for two independent design lines: one compiler-mediated and semantic-layer-centric, the other multi-agent and RL-centric. This ambiguity matters because benchmark results, failure modes, and implementation burdens are not directly comparable across the two.

2. Semantic-layer-mediated MARS-SQL

The semantic-layer-mediated system is organized into four tiers: an orchestration tier, a QUVI NL2SQL service, a deterministic SMQ-to-SQL engine, and a multi-backend executor. The orchestration tier loads benchmark instances, dispatches them in parallel, manages retries and timeouts, and routes execution. The QUVI service hosts the LLM agent and semantic layer; for each question it finds relevant semantic models, runs a constrained think-act loop, and sends SMQs to the compiler. The deterministic engine compiles an SMQ into dialect-correct SQL, resolving semantic elements to physical expressions and injecting join predicates from the semantic join graph. The executor runs the final SQL on SQLite, BigQuery, or Snowflake (Kim et al., 30 Jun 2026).

Its key abstraction is the semantic model, which wraps each physical table in business-oriented terms. Semantic elements are typed as dimensions, measures, and metrics. Each element has a human-readable description for the LLM and an exact physical expr field used by the compiler. Inter-model joins are declared once in a join graph with source model, target model, join key, and join predicate. This removes the requirement that the model rediscover join logic or infer opaque physical names directly from raw schemas.

The Semantic Model Query (SMQ) is the structured bridge between the agent and compiler. It is a compact JSON object with three lists: metrics, filters, and group_by. Its naming convention uses ModelName__elementName for dimensions and measures, and bare names for metrics. SMQ is intentionally not full SQL: it covers selection, filtering, grouping, and declared joins, but does not express arbitrary subqueries, CROSS JOINs, window functions, recursive CTEs, or other advanced constructs. The restriction is deliberate. SMQ is used for exploration and grounding, while harder SQL is composed later from compiler-generated building blocks.

The agent uses a constrained ReAct-style loop with one tool call per turn. The available tools are getModelDataElements, convertSmqToSql, and execute. Each SMQ compilation acts as a grounding probe: it reveals physical table and column mappings, join patterns, dialect-specific syntax, and a five-row result preview. The paper states explicitly that semantic model names must never be used directly as physical tables in executed SQL; only names lifted from compiler output are allowed. This design makes the trajectory auditable and constrains the action space.

Evaluation is reported on Spider2-snow, a benchmark of 547 enterprise NL2SQL tasks executed against Snowflake, using Gemini 3 Pro (preview), temperature 0.1, extended thinking enabled at high setting, output budget 16,384 tokens, and a maximum of 20 SMQ iterations per instance. The system achieves 515 correct answers out of 547, or 94.15% execution accuracy, with a breakdown of 131/135 for sf_local, 24/25 for sf_ga, 350/369 for sf_bq, and 10/18 for native sf. The paper states that this ranks third on the official leaderboard and greatly exceeds several schema-only approaches on the same benchmark (Kim et al., 30 Jun 2026).

3. Multi-agent reinforcement-learning MARS-SQL

The RL-based system comprises three specialized agents: a Grounding Agent for schema linking, a Generation Agent for query generation, and a Validation Agent for final selection. Given a question $Q$ and schema $S$, the Grounding Agent decides whether each table is relevant, $d_i \in \{\text{Y}, \text{N}\}$, and, if relevant, which columns matter, $C'_i \subseteq C_i$. Its output is a reduced schema

$S' = \{(t_i, C'_i) \mid d_i = \text{Y}\}.$

This pruning step narrows the search space and is intended to reduce hallucinations (Yang et al., 2 Nov 2025).

The Generation Agent is the core component. It reformulates Text-to-SQL as an MDP $(\mathcal{S}, \mathcal{A}, P, R)$ in which the state $s_t$ is interaction history up to turn $t$, the action $a_t = (h_t,\alpha_t)$ consists of a generated thought and SQL action, the transition dynamics are induced by live database execution, and the reward is assigned to the final trajectory. A trajectory has the form

$$\tau = (h_1,\alpha_1,\omega_1,\dots,h_M,\alpha_M,\omega_M),$$

where $S$0 is the environment observation after executing SQL. The agent follows a ReAct-style Think-Act-Observe loop: it reasons about the current state, emits executable SQL, observes a result table, empty result, or execution error, and revises its strategy over multiple turns.

Training uses Group Relative Policy Optimization (GRPO). The generator receives a sparse terminal reward:

$S$1

The paper characterizes this reward as deliberately coarse, forcing the model to discover useful interaction strategies rather than imitate annotated reasoning traces. The Grounding Agent is also trained with GRPO, but with reward shaping that grants partial credit for high-recall schema selection: perfect match gives 1.0, correct relevance and column superset gives $S$2, false positive relevance gives 0.2, missing columns gives 0.1, and invalid format gives 0.0.

The Validation Agent reranks multiple generated trajectories. It is trained by supervised fine-tuning on "Yes" versus "No" labels indicating whether a trajectory yields a correct execution result. At inference it operates as a generative verifier, scoring a candidate by the average next-token probability of generating "Yes" over multiple stochastic reasoning rounds:

$S$3

The final trajectory is selected by $S$4. This is a learned verifier rather than majority vote or a separate discriminative classifier.

Experiments use Qwen2.5-Coder-7B-Instruct as the base model for grounding and generation, and Qwen2.5-Coder-7B-Instruct fully fine-tuned for validation. Training is conducted on NVIDIA H800 GPUs, with Verl for grounding and generation RL, SkyRL-adapted rollouts for the generator, and Llama Factory for validation SFT. Reported performance is 77.84% EX on BIRD-dev, 89.75% EX on Spider-test, and 78.13% EX on Spider-DK. The paper presents these as new SOTA on BIRD-dev and Spider-test and second-best on Spider-DK. It also reports BIRD-dev grounding recall and precision of 97.78% and 90.74%, respectively, and shows a strong best-of-$S$5 effect, with best-of-1 at 69.30 and best-of-32 at 87.54 (Yang et al., 2 Nov 2025).

4. Architectural comparison

The two MARS-SQL systems share an insistence on explicit grounding and nontrivial inference-time search, but they operationalize these principles differently.

Aspect	Semantic-layer-mediated MARS-SQL	RL-based MARS-SQL
Primary setting	Enterprise NL2SQL over heterogeneous databases	Text-to-SQL on BIRD, Spider, Spider-DK
Grounding substrate	Curated semantic layer and join graph	Grounding Agent with schema linking and pruning
Intermediate object	SMQ (metrics, filters, group_by)	Multi-turn interaction trajectory $S$6
Main control loop	One tool call per turn with deterministic compilation	ReAct-style Think-Act-Observe with live execution
Selection mechanism	Compiler-mediated grounding plus final execution	Validation Agent as generative verifier
Reported headline result	94.15% execution accuracy on Spider2-snow	77.84% EX on BIRD-dev; 89.75% EX on Spider-test

This comparison suggests two complementary design philosophies (Kim et al., 30 Jun 2026, Yang et al., 2 Nov 2025). The semantic-layer-mediated system reduces uncertainty before SQL generation by replacing raw physical schemas with curated business abstractions and deterministic compilation. The RL-based system accepts a less structured schema interface but learns to search, execute, and self-correct through interaction. In one case, much of the correctness burden is shifted to the semantic layer and compiler; in the other, it is shifted to multi-turn policy learning and trajectory verification.

The contrast is also methodological. The semantic-layer-mediated system is centered on a constrained intermediate representation and a trusted compiler. The RL system is centered on an executable environment, best-of-$S$7 trajectory sampling, and a verifier trained to score correctness. Neither is a purely schema-only LLM baseline, and both explicitly reject the assumption that raw-schema prompting is sufficient for difficult SQL tasks.

5. Relation to adjacent research

MARS-SQL sits within a broader family of execution-aware SQL systems, but adjacent work clarifies that several nearby tasks are distinct. PARROT defines cross-system SQL translation, also called SQL-to-SQL, where the objective is to rewrite a query from one DBMS dialect into an equivalent query for another system while preserving semantics and target-system syntax. It is explicitly not another Text-to-SQL benchmark. PARROT contains 598 manually verified translation pairs from 38 open-source benchmarks and real-world business services, provides PARROT-Diverse with 28,003 translations and PARROT-Simple with 5,306 representative samples, covers 22 production-grade database systems, and evaluates with $S$8 and $S$9 under a reference-executor style protocol. The abstract reports that LLMs achieve lower than 38.53% accuracy on average. This distinguishes dialect migration from the NL2SQL/Text-to-SQL settings addressed by both MARS-SQL systems (Zhou et al., 27 Sep 2025).

MSc-SQL is closer in spirit to the RL-based MARS-SQL line. It is an open-source small-language-model pipeline with three stages—schema linking, SQL generation, and multi-sample critiquing—and its central contribution is a critique model that jointly evaluates multiple candidate SQL queries together with their execution results. The paper explicitly situates it relative to “MARS-SQL-style systems” as part of a broader pattern of generating multiple candidates and using second-stage selection at inference time. Reported scores are 65.6 EX on BIRD dev and 84.7 EX on Spider test, with the critique model outperforming independent scoring and self-consistency. This places multi-sample selection and execution-aware verification in a shared methodological neighborhood with MARS-SQL, even though the training regime and system decomposition differ (Gorti et al., 2024).

A more distant but conceptually relevant antecedent is FACTORBASE, introduced in “SQL for SRL: Structure Learning Inside a Database System.” FACTORBASE argues that relational algebra, implemented in SQL, should be the representation and execution substrate for statistical-relational learning inside the DBMS. It represents random variables, sufficient statistics, parameter estimates, model structures, and scores as relational tables; uses joins and aggregates for sufficient statistics; uses views for automatic dependency propagation; and reports scalability to over $d_i \in \{\text{Y}, \text{N}\}$0 records, up to 15 million sufficient statistics, and 10 to 100× block-prediction speedups on six benchmark databases. A plausible implication is that the semantic-layer-mediated MARS-SQL variant belongs to a longer design tradition in which database abstractions and database-native operators are not merely storage mechanisms but active components of reasoning systems (Schulte et al., 2015).

6. Limitations, misconceptions, and open questions

The semantic-layer-mediated paper is explicit that its reported gains should not be interpreted as a pure backbone-model comparison. It compares against schema-only approaches, but also notes that the semantic layer encodes domain knowledge that those baselines do not have. The result therefore demonstrates the power of the full system rather than only the underlying LLM. It further identifies several limitations: SMQ is intentionally limited to the common analytical core; evaluation is only on Spider2-snow; execution accuracy has edge cases; the native Snowflake subset is small and high-variance; and performance is entangled with how carefully each database’s semantic layer was authored. The paper also describes a Goodhart-style tension: if descriptions are tuned too aggressively to benchmark questions, they may become verbose, question-specific, or implicitly leak answers, reducing robustness to unseen questions or schema changes (Kim et al., 30 Jun 2026).

The RL-based paper does not present an equally long dedicated limitations section, but several constraints are stated or implied. The generator can still produce invalid SQL or logically wrong filters; verification cannot rescue failure if all sampled trajectories are poor; the grounding stage must preserve recall; and multi-turn RL plus multiple rollouts increases compute cost relative to one-shot methods. The same paper shows that candidate diversity matters, that more interaction turns improve both greedy and best-of-$d_i \in \{\text{Y}, \text{N}\}$1 performance, and that removing either the Grounder or Verifier hurts BIRD-dev accuracy. These findings indicate that the system’s gains depend on the joint efficacy of schema pruning, interactive execution, and learned reranking rather than on any single component alone (Yang et al., 2 Nov 2025).

Two broader misconceptions follow. The first is terminological: MARS-SQL is not a single architecture but a reused name for at least two distinct systems. The second is evaluative: high execution accuracy does not isolate one source of improvement. In the semantic-layer-mediated system, accuracy is strongly linked to semantic-layer quality, declared join edges, and deterministic compilation. In the RL-based system, accuracy depends on multi-turn exploration, live execution feedback, and verifier quality. For both lines of work, the open research question is not merely how to make a larger model generate SQL, but how to couple grounding, intermediate structure, environment interaction, and verification so that SQL correctness remains stable under realistic schemas, heterogeneous dialects, and long compositional queries.