Smaller Models, Smarter SQL: Arctic-Text2SQL-R1 Tops BIRD and Wins Broadly

Natural language interfaces have made it easier than ever to “talk to your data,” but turning a question into working SQL remains a surprisingly hard problem. SQL’s power lies in its structure and precision, but that same rigidity makes it inaccessible to most users. And while large language models (LLMs) offer a promising bridge, they often falter under real-world demands: multi-table joins, nested logic, ambiguous intent and messy schemas.

What if natural language interfaces could do more than simply translate your question? What if they could reason through the structure of your data to understand the intent behind your question to generate SQL that works?

Introducing Arctic-Text2SQL-R1 — a new family of reasoning-first models from Snowflake AI Research that rethinks how natural language gets translated into structured, executable SQL. Instead of mimicking what SQL “should” look like, it learns what actually works — with simple reward signals grounded in execution accuracy.

These models are No. 1 on the BIRD benchmark: Arctic-Text2SQL-R1 32B achieves the highest execution accuracy of any open or proprietary model.¹

Beyond BIRD, Arctic-Text2SQL-R1 models demonstrate strong generalization and efficiency: 

• State-of-the-art results at every scale across benchmarks: Consistent performance across six diverse and challenging text-to-SQL benchmarks.
  

• Breakthrough in parameter efficiency: The 7B model, with 95x fewer parameters, outperforms open source giants like DeepSeek-v3 and even commercial models like GPT-4o.

The result: better accuracy, smaller models and faster inference — built to meet the quality and efficiency demands of enterprise AI.

In this blog, we’ll break down why Text-to-SQL accuracy is so elusive, walk through our design approach and share key learnings from building Arctic-Text2SQL-R1 to achieve these results. We’ll also show how to get started with the open source release.

The lingering challenge: Why Text-to-SQL is still hard

Turning a simple question into a simple SQL query is easy. But real-world data analysis? That’s a different story. It’s full of edge cases and complexity that break most models.

Traditional LLMs can generate SQL that appears correct, but the code breaks down when it matters. That’s because they’re trained to mimic how SQL looks, not trained to produce code that actually works. The result may seem plausible, but it’s frequently invalid, incomplete or just wrong.

Here’s why:

• Complex relationships: Ask for “total sales of eco-friendly products to customers in New York last quarter,” and you’re touching five or more tables — products, categories, orders, order items, customer addresses — all linked through fragile joins. A joining misstep can lead to wildly inaccurate results, or no results at all.

• Nested logic: Take a question like: “Which employees earned more than the average salary in their department and joined in the last two years?” Answering this means first calculating average salaries per department — typically with a subquery or CTE — then filtering employees by that dynamic threshold and hire date. It’s multi-step reasoning, and models often miss the full chain.

• Language ambiguity: A request like “Show me our top-performing products” sounds simple — but what does “top-performing” actually mean? Is it based on revenue, profit margin, units sold or customer ratings? The model has to infer intent, often without context, and map it to the right metric — like sales_volume, profit_margin, or review_score. Without that understanding, the query may technically work but deliver the wrong answer.

• Messy, opaque schemas: In real-world databases, column names aren’t always helpful: trn_val_01 might actually mean transaction_value. Relationships between tables may be undocumented or loosely defined, and data types can be inconsistent. To write valid SQL in this environment, a model needs to reason through ambiguity and pick up on subtle clues across the schema.

In short, Text-to-SQL isn’t just a language task. It’s a reasoning problem over often-imperfect data.

Our approach to Arctic-Text2SQL-R1: Simple rewards, strong reasoning

To tackle these challenges, we designed Arctic-Text2SQL-R1 around a simple philosophy: Focus on what matters most — whether the query works. 

As shown in Figure 1, our approach centers on execution correctness, with a training pipeline that combines data filtering, step-by-step reasoning and a direct reward signal tied to real query results. So, instead of optimizing for how SQL looks, we train models to generate SQL that runs — and returns the right answer.

This led us to three key design principles:

1. Execution-aligned reinforcement learning (RL): The power of real-world feedback

Many Text-to-SQL models rely on complex, handcrafted reward functions that guess whether a query might be correct. That often turns into a feedback loop failure: The model learns to chase the proxy signal, not actual performance.

We skipped the guesswork. Our reward is simple and grounded: Did the SQL run? Did it return the right answer? This direct feedback forces the model to learn what actually works — against a real, live database — and to produce SQL you can trust, not just SQL that looks right.

To make this work in a sparse-reward setting — where many early queries fail — we use Group Relative Policy Optimization (GRPO), a reinforcement learning technique built for noisy environments with limited successes. It’s stable, effective and keeps the model focused on one thing: generating queries that work in the real world.

2. Data-centric training: Curate, don’t accumulate

The old adage holds: More data doesn’t mean better data — especially in Text-to-SQL.

For Arctic-Text2SQL-R1, we didn’t just collect data; we curated it. We started by filtering established benchmarks like BIRD and SPIDER, targeting not just errors but noise — queries that return empty results or take ages to run. Those examples don’t teach useful reasoning and just slow everything down. Cleaner data meant a clearer signal for learning.

But we didn’t stop there. To scale complexity and coverage, we turned to synthetic data — generating new Text-to-SQL examples with models like GPT-4o. Then came the crucial step: model-based filtering. We used Arctic-Text2SQL itself to vet the generated queries, keeping only the ones that executed correctly and matched the expected results.

It’s a virtuous cycle: Use better models to get better data, then use that data to train even better models. The end result? It gives Arctic-Text2SQL-R1 the range to generalize across the messy, multistep and often ambiguous questions analysts face every day.

3. Systematic exploration of training strategy: Learn faster by doing it right

Our training strategy for Arctic-Text2SQL-R1 began with a careful evaluation of optimization algorithms. We compared GRPO and Proximal Policy Optimization (PPO), and found GRPO consistently outperformed PPO for Text2SQL tasks.

Choosing the right starting model proved equally important. Models such as Qwen-2.5-Coder-Instruct or supervised fine-tuned variants such as OmniSQL — already strong in instruction-following and accuracy — provided a significant advantage. In contrast, models that started with lower accuracy, even those trained on other reasoning tasks, failed to catch up during RL fine-tuning.

We also found that the mode of reinforcement learning (RL) interaction matters. Online RL — where the model interacts continuously with the environment — led to stronger results than batch RL. We attribute this to online RL’s ability to adapt dynamically and learn from diverse, complex negative examples encountered in live training. This aligns with observations in math and programming domains and now extends to Text2SQL as well.

Prompt structure emerged as another critical factor. Switching from a generic prompt to a carefully adapted version of the OmniSQL prompt — designed for RL — resulted in significant gains. Key improvements came from structuring the prompt effectively, including “thinking” instructions and optimizing how the database schema is serialized.

Interestingly, while we experimented with more fine-grained reward functions, these often backfired — encouraging "lazy" behaviors where models optimized for short-term gains rather than global correctness. In contrast, our simpler, execution-driven reward signal proved more effective, reinforcing desired behaviors without introducing perverse incentives.

Breakthrough performance: Smaller, smarter and state-of-the-art

The combination of execution-based training, clean data and strong initialization paid off. Arctic-Text2SQL-R1 doesn’t just improve on the status quo — it sets a new bar for performance, efficiency and reliability in Text-to-SQL.

Arctic-Text2SQL-R1 leads the BIRD benchmark

BIRD, one of the most rigorous Text-to-SQL benchmarks available, evaluates real execution accuracy on complex, multitable, real-world queries. Arctic-Text2SQL-R1 doesn’t just perform well on BIRD; it dominates, with best-in-class results across every model size.