Feyn AI’s SQRL: A Text-to-SQL Model That Checks the Database First

Y Combinator-backed Feyn AI has released SQRL, a family of open text-to-SQL models that inspect a live database before writing a query. Rather than guessing from a schema alone, SQRL runs read-only exploration queries to resolve ambiguity, then commits to a final answer. The flagship SQRL-35B-A3B scores 70.6% execution accuracy on the BIRD Dev benchmark, beating Claude Opus 4.6 (68.77%) under the same evaluation. All three model sizes are available on Hugging Face.

What happened

Detail	Fact
Company	Feyn AI (YC-backed)
Product	SQRL model family
Models released	SQRL-4B, SQRL-9B, SQRL-35B-A3B
Where available	Hugging Face (open weights)
Flagship benchmark score	70.60% on BIRD Dev (execution accuracy)
Comparison model	Claude Opus 4.6 at 68.77%
Base model families	Qwen3.5 and Qwen3.6
Training method	CISPO (reinforcement learning from MiniMax’s M1 work)

Most text-to-SQL tools treat the job as a translation task: read the schema, write the SQL. Feyn AI’s SQRL takes a different approach. It first decides whether it has enough information to write a correct query. If not, it runs short read-only queries against the actual database, reads the returned rows, and uses that information to draft its final answer.

The model uses two distinct output blocks. An <sql> block triggers an exploration query. An <answer> block commits to the final result. A controlling harness executes those exploration queries in read-only mode and returns rows inside <observation> tags. SQRL can inspect up to five times, though simpler questions finish in fewer steps or none at all.

Why does schema-only SQL generation fail?

A schema tells a model which tables and columns exist. It does not reveal how values are actually stored. A county might appear as “Alameda”, “Alameda County”, or “ALAMEDA” depending on whoever entered the data. A schema cannot flag which joins produce duplicate rows or which filter values have zero matching records.

These errors are silent. The query executes without throwing an error and returns rows, just the wrong ones. The BIRD benchmark (Benchmarking the Intelligence of Real-world Databases) is designed to expose exactly this class of mistake. Its databases span real domains with imperfect values and ambiguous columns, and a system is scored only when its query returns the same rows as the reference answer.

Feyn’s argument is that the information needed to avoid these mistakes already exists inside the database. The model just needs to look before it writes.

How the model family performs

Model	BIRD Dev Accuracy	Active Parameters per Token
SQRL-35B-A3B	70.60%	~3B
SQRL-9B	69.80%	9B
SQRL-4B	68.80%	4B
Claude Opus 4.6	68.77%	not disclosed

The 9B student retains almost all of the flagship’s accuracy. The 4B model matches Claude Opus 4.6 at a fraction of the serving cost, and its size makes on-premise deployment realistic for teams with data privacy requirements.

How Feyn trained the inspection behavior

Giving a model database access is straightforward. Teaching it when to use that access is harder. Feyn started with the BIRD and Spider training sets and removed examples where the reference SQL produced no usable result. Three model judges then reviewed remaining pairs and cut any query that did not actually answer its stated question.

The 35B-A3B teacher was then trained 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. For each question the model produced eight complete trajectories, each trajectory ending with a query that was either executed and matched the reference or did not. Only groups where some attempts succeeded and some failed carried useful training signal, so Feyn focused training on that “mixed zone.”

Correct teacher trajectories were sampled to produce roughly 10,200 examples, each preserving the full chain: reasoning, exploration queries, observations, and final answer. The 4B and 9B students were fine-tuned on these trajectories, then refined further with the same CISPO execution reward.

Our take

The core idea here is genuinely useful and underappreciated. “My SQL is syntactically correct but logically wrong” is one of the most common complaints from teams who have deployed any kind of natural language database interface. SQRL addresses that problem at the architectural level rather than patching it with longer prompts.

The cost story is also credible. Multi-step frontier pipelines (generate, critique, select) can easily spend five or more API calls per question. SQRL bundles that reasoning into a single model that only pays the inspection cost when it actually needs to. For high-volume analytics tooling or internal reporting dashboards, that difference adds up quickly.

The caveat is that BIRD Dev is one benchmark. Real-world databases are messier, and inspection helps only if the model chooses the right exploration queries. Teams considering this for production should run it against their own schemas before drawing conclusions from the leaderboard numbers.

If you are building an internal data tool or AI-powered reporting layer, this is one of the more concrete open-weight options to appear this year. Our AI integration work regularly involves exactly this kind of natural language to database query layer, and the SQRL approach cuts several steps out of a typical pipeline. You can also follow more model releases and AI tooling news on the Lumien news feed.

Start with the 4B checkpoint. If accuracy on your data is acceptable, you can keep costs low and keep data on-premise. Step up to 9B only if the 4B results show gaps.

Source: Marktechpost