SQRL Digs Before It Queries

Community Article
Published July 16, 2026

Introducing SQRL, a family of models that convert natural language questions to SQL queries. SQRL reaches 70.6% execution accuracy on BIRD Dev, compared to 68.77% for Claude Opus 4.6.

Instead of immediately generating SQL, SQRL can inspect the database before committing to an answer. This allows it to resolve ambiguities and only write queries the data supports.

SQRL-35B-A3B is our flagship model. To enable low latency deployments, we distilled it into 4B and 9B students. The smaller models retain nearly all the teacher's quality at a fraction of the size.

The models are available on Hugging Face. Deployment instructions are below.

Don't Judge a Query by its Looks

Text-to-SQL is often described as a translation problem. Users ask questions in natural language and a model writes the corresponding SQL. However, this misses the hardest part of the task.

A query can be valid SQL and still be wrong. It can join the wrong tables, interpret an ambiguous column incorrectly, or filter for non-existent values. None of these throw an error, but they all produce the wrong answer.

Schema information alone is not enough to query well. While it provides table and column names, types, and sometimes relationships, it does not show whether a county is stored as Alameda, Alameda County, or ALAMEDA. It does not explain whether two similar identifiers refer to the same entity. It cannot show which join produces duplicate rows.

The BIRD benchmark makes these failures visible. Its 95 databases span real domains and contain imperfect values, ambiguous columns, and nontrivial relationships. A system is scored by executing its SQL and comparing the returned result with the reference result. BIRD shows us that for query languages, syntax correctness is not enough.

The information we need to accurately generate queries already lives inside our database. We simply have to enable the model to ask for it. SQRL is built around this insight.

SQRL Inspects Before Answering

SQRL receives a question, its schema, and optional evidence about the database structure or its contents. If that context is enough, SQRL returns a query immediately. If something remains ambiguous, SQRL runs read-only queries and uses the returned rows to draft its query.

The decision to inspect is circumstantial. For example, counting rows does not need a data look up. That's why in the example below, SQRL simply returns a query.

SQRL answers directly when the schema contains enough information

However, running a filter requires knowledge about how your match condition is stored. In the example below, SQRL first inspects the database to find how the target string is stored, then returns an answer.

SQRL inspects stored values before answering an ambiguous question

Such interactions have two distinct actions. An <sql> block requests an observation from the database. An <answer> block commits to the final query. The harness executes exploration queries in read-only mode and returns their rows inside <observation> tags. SQRL can inspect up to five times, though most questions run in fewer steps.

Traditionally, text-to-SQL has followed two approaches.

  • Single-shot models are inexpensive to serve and generate the entire query in one turn. However, they must infer everything from the schema, which can lead to logically incorrect queries.
  • Frontier pipelines retrieve context, generate candidates, critique them, and then select an answer. This can maximize accuracy, but every question requires several expensive frontier model calls and multiple database round trips. That makes them difficult to use on the hot path.

SQRL combines the best of both approaches in one model. Easy questions stay short while ambiguous questions earn an inspection.

Training the Decision to Inspect

Simply giving a model access to the database does not teach it when or how to look. It has to be trained.

Execution-based training is unforgiving. If the reference query is wrong, a correct model answer receives the wrong reward. We therefore cleaned the training pool before training any model.

Starting with BIRD and Spider, we removed examples whose reference SQL did not produce a usable result. Then, three model judges reviewed the remaining question and query pairs. All examples where the query did not answer the question as written were dropped. Finally, we created our test split by splitting Spider and combining it with BIRD dev. The rest of the data was used in training.

Cleaning gave us reliable rewards. We could now train the teacher.

We trained the 35B-A3B teacher directly with CISPO (MiniMax, 2025). For each question, the model produced eight complete trajectories. We executed every final query and compared its result with the reference query.

predicted_result = execute(predicted_sql)
gold_result = execute(gold_sql)

reward = int(predicted_result == gold_result)

The reward follows the same principle as the benchmark. It ignores whether two queries use the same words and checks only whether they return the same answer.

Group-relative training needs variation within each group. Eight correct attempts produce identical rewards and little information about which decisions helped. Eight failures have the same problem. We therefore trained the teacher on the mixed zone, where only some of its eight attempts succeeded. Every group could then reinforce the choices that separated a correct trajectory from an incorrect one. This way, the teacher model learned when to inspect.

Our next challenge was making this behavior small enough to deploy.

We sampled complete teacher trajectories and kept only the runs whose final SQL returned the correct result. This produced about 10,200 examples. Each example preserved the reasoning, exploration queries, observations, and final answer.

The 4B and 9B students were then fine-tuned on these trajectories. Because each example contained the full interaction, both models learned the complete path from question to inspection to final query.

Both students then went through CISPO training with the same execution reward. This helped us further refine their behavior.

SQRL teacher training and student distillation flow

Performance Across the Family

We evaluated SQRL on BIRD Dev. A generated query counts as correct when it returns the same result as the reference query.

SQRL execution accuracy on the BIRD development benchmark

SQRL-35B-A3B scores 70.60%, beating Claude Opus' 68.77%. The 9B student retains nearly all the teacher's quality at 69.80%.

The practical result is SQRL-4B. It reaches 68.80%, matching Opus on BIRD Dev in a model you can host anywhere. Your schema, queries, and database observations stay on a data path you own entirely. No need to share your data with any third parties.

Run SQRL Beside the Database

The three checkpoints serve different deployment budgets. SQRL-4B is the smallest. SQRL-9B is our recommended default. SQRL-35B-A3B delivers the highest accuracy and activates about 3B parameters per token.

Serve the 9B model with vLLM:

vllm serve feyninc/sqrl-9b \
  --served-model-name sqrl-9b \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

The application loop is small. Keep database execution read-only and return each observation to the model.

reply = generate(question, schema)

for _ in range(5):
    if answer := extract_answer(reply):
        return answer

    probe = extract_probe(reply)
    observation = run_readonly(probe)
    reply = continue_with(observation)

Do not enable a serving-layer reasoning parser. The action protocol appears in the content after </think>. Stripping that content removes the model's <sql> or <answer> action. Parse the raw message content and preserve everything after the final closing think tag.

The model cards contain the complete system prompt and reference harness:

SQL is partly asking the right questions and partly knowing what your data looks like. SQRL understands this and turns it into behavior small models can carry into production.

SQRL is built by Feyn. Find us on GitHub, Hugging Face, or X.

Acknowledgements

SQRL builds on the Qwen3.5 and Qwen3.6 model families. The BIRD and Spider teams created the benchmarks and training pools behind this work. CISPO comes from MiniMax's M1 research. We are grateful that this work is available to build on

References

[1] Li et al. "Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs." NeurIPS 2023. arXiv:2305.03111.

[2] Yu et al. "Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task." EMNLP 2018. arXiv:1809.08887.

[3] MiniMax. "MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention." arXiv:2506.13585 (2025).

[4] Wang et al. "Self-Consistency Improves Chain of Thought Reasoning in Language Models." ICLR 2023. arXiv:2203.11171.

Community

Sign up or log in to comment