Your Data Can Answer Questions — But Not If Your Tools Guess First
You own a small business in Malaysia. You’ve got customer records, inventory numbers, sales history — all sitting in a database somewhere. Every week, you need answers: Which products are sitting too long? Which clients haven’t ordered in months? What’s the trend for this quarter? But getting those answers usually means either bugging a tech person or spending hours wrestling with spreadsheets. New AI tools promise to let you just type your question in plain English and get the data back. The problem? Most of them guess — and when they guess wrong, you get a clean-looking report with the wrong numbers. That’s worse than no answer at all.
TL;DR: A YC-backed startup called Feyn AI just released SQRL, a family of AI models that turns your plain-English questions into SQL queries — but unlike other tools, SQRL checks your actual database data before writing the final query. This catches ambiguous column names, wrong table joins, and missing values before they produce bad answers. The smallest model runs on your own infrastructure. You can test all three sizes on Hugging Face today.
Why Guessing SQL Is a Trap for Business Owners
Most text-to-SQL tools treat your question like a translation exercise. You say “Show me top-selling items last month,” and the model writes a query and runs it. If the SQL is syntactically correct, the tool calls it a win. But as the Feyn AI team points out, that approach misses the hardest part: a query can be valid SQL and still be flat-out wrong.
Imagine you ask for sales in “Selangor,” but your database stores locations as “Selangor Darul Ehsan.” The SQL runs fine — it just returns zero rows. Or the model joins the wrong tables and gives you duplicate customer counts. These aren’t technical errors. They’re logic errors, and they’re invisible to any system that only checks whether the query ran without crashing.
The BIRD benchmark measures this exact failure mode. It tests against real-world databases with messy data, ambiguous column names, and complicated relationships. Scoring is based on whether the returned rows match the correct answer — not whether the SQL looks pretty. Most models stumble badly here because they never look at the actual data before committing to a query.
“A query can be perfectly valid SQL and still return the wrong answer. It can join the wrong tables, read an ambiguous column incorrectly, or filter for values that do not exist.” — Feyn AI, via MarkTechPost
For you as a business owner, this means trusting a “smart” tool without verification is a gamble. A report that looks right but has wrong numbers can lead to bad inventory orders, missed follow-ups with key clients, or misreading your cash flow. That’s the real cost — and it’s not about software pricing.
How SQRL Works: It Peeks at Your Data Before It Writes
SQRL flips the approach. Instead of generating a final query immediately, it can first inspect the database using read-only queries. The model decides when to look — easy questions get answered straight away, while ambiguous ones trigger one to five exploration rounds.
The system uses two simple actions:
- <sql> block — the model runs a read-only query to check something (e.g., “what values exist in this column?”)
- <answer> block — the model commits to the final query
The database returns rows inside <observation> tags, so the model can see actual data patterns before writing its final answer. According to the Feyn team, most questions finish in fewer than five inspection steps. The result is a query that’s not just valid — it’s correct for your specific data.
This “inspect first” behaviour didn’t happen by accident. The team trained the model using a method called CISPO, a reinforcement learning approach that rewards queries that return the right rows, not just syntactically correct ones. For each training question, the model tried eight different strategies. Only the attempts that landed on the correct result were used to teach the next iteration. That’s how SQRL learned when to inspect and what to look for.
Three Sizes, One Approach — Which One Fits You?
SQRL ships in three sizes on Hugging Face. All three follow the same inspect-first logic, but they differ in accuracy and resource requirements.
| Model | BIRD Dev Accuracy | Best For |
|---|---|---|
| SQRL-4B | 68.80% | Tight compute budgets, full data privacy |
| SQRL-9B | 69.80% | Default choice — balances accuracy and cost |
| SQRL-35B-A3B | 70.60% | Highest accuracy, uses ~3B parameters per token |
All numbers are from the BIRD Dev evaluation under the same conditions. For context, SQRL-4B matches Claude Opus 4.6 (68.77%) despite being small enough to run on your own hardware. The 9B model is Feyn’s recommended default. The 35B-A3B edges ahead of Claude 4.5 Sonnet (67.34%) and other frontier models.
What’s probably most relevant for you as an SME owner: the 4B and 9B models can run on your own infrastructure. Your schema, your queries, and your inspection observations stay on equipment you control. No third-party API sees your customer data or sales figures — which likely matters if you handle sensitive business records.
The Bigger Picture: What This Means for Malaysian SMEs
Text-to-SQL tools have been around, but they’ve mostly been too unreliable for real business use. The core problem has always been the same: they translate language, but they don’t understand your specific data. A model that inspects the database before writing a query changes that dynamic.
Think about your daily operations. You probably have data in accounting software, inventory systems, and maybe a CRM. Getting a monthly report on “which clients haven’t been contacted in 90 days” or “which products have the highest return rate” usually requires someone who knows SQL. That person may not exist in your team, or they may be too busy to stop and write queries every time you need one.
An inspect-first model won’t replace your team. But it could let you ask those questions yourself — directly, in plain English — and get answers you can trust because the model checked the data before committing. Over time, this reduces your dependency on technical staff for routine data pulls and frees them up for deeper work.
The privacy angle matters too. Unlike cloud-only AI services that send your data to external servers, SQRL’s smaller models can run locally. Your supplier list, customer behaviour, and pricing data stay within your own systems. For businesses in Malaysia where data residency and confidentiality are growing concerns, that’s a meaningful advantage — it feels like the direction things are heading, not just a niche feature.
Practical First Step
If you’re curious whether this approach could help your team get better answers from your data, the starting point isn’t downloading a model. It’s understanding what questions you’re already asking and where wrong answers currently cost you time. A quick conversation can clarify whether inspect-first text-to-SQL fits your workflow.