By Text-to-SQL has a confidence problem. Models write queries from schema metadata alone, guess at ambiguous column values, and return wrong results without a single error. The output looks like SQL. It runs like SQL. It just answers the wrong question. Feyn Labs shipped SQRL on July 19 to fix this at the model level: instead of writing SQL cold, SQRL inspects the database first with read-only probes, then writes the query. Its flagship SQRL-35B-A3B hits 70.6% execution accuracy on BIRD Dev, edging past Claude Opus 4.6 at 68.77% on the same benchmark — and all three checkpoints are open weights on Hugging Face.
This is not a marginal improvement. It is a different architecture.
How the Inspection Loop Works
Most text-to-SQL models treat the problem as translation: take the English question, convert it to SQL. The schema tells them what tables exist. It does not tell them what values are in those tables, which column named “status” means active vs. archived vs. deleted, or whether the date range in the question has any matching rows at all.
SQRL adds a step before translation. The model receives the question, the schema, and optional evidence. If context is sufficient, it writes the SQL immediately. If something is ambiguous — and in production, something usually is — it fires read-only exploration queries: SELECT DISTINCT probes, COUNT checks, LIMIT samplers. The returned rows resolve ambiguity against actual data, not metadata assumptions. Only then does it commit to a final query.
Deployment runs through vLLM with a read-only harness that intercepts exploration queries before they reach the database, executes them against a sandboxed connection, and returns the results to the model. The final SQL runs with normal credentials. The model pays the inspection cost only when the question needs it — easy queries stay fast.
Why Production Text-to-SQL Has Been Broken
The gap between benchmark scores and production reality is not subtle. GPT-4o scores 86.6% on Spider, a standard text-to-SQL benchmark. On Spider 2.0, which uses real enterprise schemas, that number drops to 10.1%. Snowflake’s team measured GPT-4o at 51% accuracy on 150 actual internal BI questions. The dbt 2026 benchmark summary: “Text-to-SQL will cheerfully give you a wrong number.”
The failure modes are consistent. Schema-based hallucinations produce column names that do not exist. Logic-based hallucinations use the right schema but wrong joins or missing filters. Value ambiguity leaves the model guessing which of three “revenue” columns in different tables the user meant. None of these produce an error. They produce a result set that goes into a report or a dashboard and gets acted on.
BIRD, the benchmark Feyn uses, is more honest than Spider: 95 real databases, 33.4 GB of actual data across 37 professional domains, execution-verified accuracy. It is harder because it is closer to production. SQRL-35B-A3B at 70.6% on BIRD Dev is a meaningful number.
Three Open Models, One Architecture
Feyn ships three checkpoints on Hugging Face: SQRL-4B, SQRL-9B, and SQRL-35B-A3B. The 35B-A3B is a Mixture-of-Experts model — 35 billion total parameters, roughly 3 billion active per forward pass, which means inference cost closer to a 3B model. Both the 4B and 9B are distilled from the teacher, trained on approximately 10,200 verified teacher trajectories that preserved the full reasoning, exploration queries, observations, and final answer.
The practical headline: SQRL-4B matches Claude Opus 4.6 on BIRD Dev while being fully self-hostable. For enterprise teams with data that cannot leave the premises, that combination — accuracy at the frontier, inference on your own hardware — is what makes this relevant beyond a research paper.
Training: Clean Data, Verified Execution
Feyn’s training approach reflects the same discipline as the architecture. Starting from BIRD and Spider, it removed examples where reference SQL produced no usable result. Three model judges reviewed remaining pairs and dropped any query that did not answer its question as written. The result was a high-quality training set where every example was execution-verified.
The 35B teacher trained directly with CISPO, a reinforcement learning method from MiniMax’s M1 work. CISPO clips importance-sampling weights rather than the policy ratio, which preserves gradient signal from rare but decisive tokens. In SQL generation, a single wrong token — wrong column name, wrong operator, wrong filter value — invalidates the entire query. CISPO’s approach to gradient preservation is specifically suited to this problem.
What This Means for Teams Building on Data
SQRL does not solve every text-to-SQL problem. Human expert performance on BIRD sits at 92.96% — there is still a 22-point gap to close. Complex multi-hop joins, deeply ambiguous business metrics, and schemas without clear naming conventions will still trip any model. The inspection loop helps with what the model does not know; it cannot help with what the schema itself does not encode.
But for teams trying to ship reliable natural language querying on real databases — not demo schemas, not perfectly documented warehouses, but actual production data — SQRL is the first open-weight model that directly addresses the right problem. Look before you write. The database knows what the schema cannot tell you.
All three models are available now on Hugging Face. The full technical writeup at MarkTechPost covers the training methodology in detail.
