DEV Community: Manikandan

Why LLM-to-SQL Breaks in Production

Manikandan — Tue, 21 Jul 2026 16:50:45 +0000

Why LLM-to-SQL Breaks in Production: The Hidden Risks Behind Natural Language Analytics

Natural language analytics has an irresistible promise.

A CEO asks, “What was our churn last quarter?”

A product manager asks, “Which feature drove the most upgrades?”

A data analyst asks, “Can I break this down by customer segment?”

The system writes the SQL, returns a chart, and everyone gets answers without waiting in the data queue.

That is the dream. And in a demo, it often works beautifully.

But production is not a demo.

Production data is messy. Schemas change. Business definitions evolve. Customer permissions matter. The same phrase can mean different things to finance, product, sales, and customer success.

When an LLM generates SQL in that environment, the biggest risk is not always that it fails.

The bigger risk is that it succeeds quietly and gives you the wrong answer.

For CEOs, CTOs, data analysts, and product managers, this matters because natural language querying is quickly becoming part of the modern analytics experience. The question is no longer whether users will want to ask questions in plain English. They will. The real question is whether the system underneath is strong enough to make those answers trustworthy.

1. The Schema Changes, But The Model Keeps Living In The Past

Most companies do not have a frozen database schema. Tables get renamed. Columns move. New lookup tables appear. Old fields stay around for backward compatibility.

A small cleanup today can change the meaning of a query tomorrow.

Imagine your revenue team asks:

What is our average deal size by region this quarter?

For months, the LLM generates a query using a region column on the accounts table. The result is correct. Everyone trusts it.

Then engineering updates the data model. Maybe region becomes sales_region. Maybe regions move into a new lookup table to support customers operating in multiple regions. The old region column still exists, but it is no longer the source of truth.

Now the LLM has a problem.

It does not automatically know that the business meaning moved. If the old column still exists, the query may still run.

No error. No alert. No obvious failure.

It just returns a number based on stale logic.

That is what makes schema drift dangerous. A broken query is easy to notice. A quietly outdated query can influence board decks, product decisions, sales forecasts, and executive dashboards before anyone realizes something changed underneath.

For a data analyst, this is a trust problem.

For a CTO, it is a systems problem.

For a CEO, it is a decision-quality problem.

The fix is not to write a better prompt and hope the model remembers more. The fix is to validate generated SQL against the live schema and the current semantic layer every time. If a field is deprecated, ambiguous, or no longer trusted, the system should fail loudly or ask for clarification instead of returning a polished-but-wrong answer.

2. The Join Has More Than One “Correct” Answer

Some questions sound simple until you ask what they actually mean.

Take this one:

How many active users do we have per customer?

Seems straightforward.

But what does “active” mean?

It could mean users who logged in during the last 30 days.

It could mean users with status = active.

It could mean users attached to an active subscription.

It could exclude paused accounts.

It could include invited users who have not logged in yet.

Every one of those definitions might be reasonable in a different meeting. Product, finance, sales, and customer success may each care about a slightly different version of “active.”

A good analyst knows to ask, “Which definition do you want?”

An LLM often does not. It chooses a path. It picks a join. It produces a clean result. And because the output looks confident, the user may never realize the system made a business decision on their behalf.

This is one of the hardest failure modes to catch because the SQL can be technically perfect. The tables exist. The joins work. The aggregation is correct. The number is internally consistent.

It is just answering a different question.

That is a serious product risk. If your analytics experience makes users feel fast but not accurate, trust erodes quietly. People stop relying on the product for important decisions. They go back to spreadsheets, Slack threads, and “Can you check this for me?” requests to the data team.

The way forward is to stop giving the model the entire database and asking it to improvise. Instead, give it approved business definitions, trusted joins, curated metrics, and a semantic layer that reflects how the company actually talks about its data.

The goal is not to make the model more creative.

The goal is to make it less free to be plausibly wrong.

3. The Query Is Valid, But The Data Boundary Is Broken

This is the failure mode every multi-tenant SaaS company should take seriously.

Suppose a customer asks:

Show me monthly revenue by plan.

The LLM writes valid SQL. It joins the right tables. It groups by plan. It returns the right shape of result.

But it forgets one thing:

WHERE tenant_id = ?

In a normal application flow, tenant scoping may be enforced by the backend. Every request is tied to a customer, workspace, organization, or account. The application knows what data the user is allowed to see.

But an LLM-to-SQL pipeline can accidentally bypass the same assumptions if generated queries are executed in a different path.

The model does not understand tenancy as a security boundary unless the system enforces it that way. To the model, tenant_id may look like just another optional column. If the user did not mention a customer or tenant, the model may not include the filter.

That is not just a wrong answer.

That is a potential data leak.

If your database already enforces row-level security, this risk is much lower because the database blocks unauthorized rows regardless of what SQL the model generates. But if tenant isolation depends only on application logic above the query execution layer, generated SQL must be treated as untrusted input.

This point is critical for CTOs and product leaders: never make the LLM the place where security is enforced.

The LLM can help create the query. It should not be trusted to protect the boundary.

The Pattern Behind All Three Failures

These issues look different on the surface:

A schema changed.
A business definition was ambiguous.
A tenant filter was missing.

But underneath, they are the same problem.

The model is optimizing for SQL that looks right and runs successfully. Production systems need SQL that is correct, current, scoped, and aligned with business meaning.

Those are not the same thing.

An LLM does not automatically know which columns are deprecated. It does not automatically know which definition of “active user” finance uses. It does not automatically know that tenant scoping is mandatory unless the infrastructure makes it mandatory.

This does not mean LLM-to-SQL is a bad idea.

It means LLM-to-SQL cannot be treated like magic.

It is an interface, not a source of truth.

What A Production-Ready Approach Looks Like

The right architecture does not ask:

How do we make the prompt perfect?

It asks:

What should still be true even when the model is wrong?

That mindset changes the system design.

Generated SQL should be validated against the live schema, not an old snapshot.

Business terms should map to approved metrics and definitions, not whatever join the model happens to choose.

Tenant isolation should be enforced below the LLM, ideally at the database or execution layer.

Dangerous queries should be blocked, rewritten, or routed for clarification.

The system should know when to say, “I need more context,” instead of pretending every question has one obvious answer.

For data analysts, this means the semantic layer becomes more important, not less. Their job shifts from writing every query by hand to defining trusted concepts that others can safely reuse.

For product managers, it means the user experience should include clarification, confidence, and explainability. A fast answer is only valuable if users understand what was counted and how.

For CTOs, it means NLQ belongs inside the same reliability and security model as the rest of the platform.

For CEOs, it means AI analytics can speed up decision-making, but only if the foundation protects the business from confident misinformation.

The Real Promise

Natural language analytics is not exciting because it removes SQL.

It is exciting because it removes unnecessary friction between people and data.

But friction is not always bad. Sometimes friction is a guardrail. Sometimes the pause before an answer is where an analyst catches an ambiguous definition, a missing filter, or a schema change that would have produced the wrong number.

The best LLM-to-SQL systems will not remove all of that thinking. They will move it into the product architecture.

They will make trusted definitions reusable. They will make permissions unavoidable. They will make schema changes visible. They will make ambiguity explicit.

That is when natural language querying becomes more than a demo.

It becomes something a business can actually trust.

The demo works when nothing goes wrong.

Production works when the system is built assuming something eventually will.

What Nobody Tells You About Enterprise Schemas and NLQ

Manikandan — Thu, 16 Jul 2026 04:41:44 +0000

What Nobody Tells You About Schema Complexity When You're Building NLQ

When we first got natural language querying working end to end, the demo was clean. Ten tables, obvious relationships, column names that matched what a business user would actually say out loud. "Show me revenue by region last quarter" turned into a correct SQL query almost every time.

Then we pointed it at a real customer schema. Two hundred and forty tables. Column names like acct_stat_cd and txn_ln_amt_2. Three different tables that all had something called customer_id, none of which meant the same thing. That's when the actual problem revealed itself — and it's not really about generating SQL. It's about figuring out which twelve tables out of two hundred and forty are even relevant to the question in the first place.

I want to walk through the three layers of this problem in the order we ran into them, because each one exposes a different failure mode, and each one needed a different kind of fix.

Layer one: table and column selection

The first wall we hit was simple in hindsight — you can't just stuff a full schema into a prompt and hope the model figures out what matters. Even with generous context windows, dumping 240 tables' worth of DDL in front of an LLM does two bad things. It buries the relevant tables in noise, and it gives the model plausible-looking but wrong tables to hallucinate joins against. A model that's seen orders, order_items, order_archive, and orders_v2 in the same prompt will happily pick the wrong one with total confidence.

The fix here is retrieval, not reasoning. Instead of asking the model to read the whole schema and decide what's relevant, we narrow the candidate set first — surfacing a small, high-confidence subset of tables and columns based on the query — and only then hand that subset to the model for SQL generation. Smaller surface area, fewer plausible wrong answers.

This layer is the most "solved" of the three. Retrieval over schema metadata is a well-understood pattern at this point. It's not perfect, but it's tractable.

Layer two: join path resolution

Getting the right tables doesn't get you the right query. The second wall is figuring out how those tables actually connect — and this is where things get genuinely messy in enterprise schemas.

Foreign keys are often missing, inconsistently enforced, or simply wrong relative to how the data is actually used. A customer_id column might exist in five tables, but only three of those relationships are meaningful for a given business question, and the "correct" join path frequently isn't the shortest one — it's the one that matches how the business actually thinks about the relationship. Two tables might be joinable three different ways, each producing a technically valid but semantically different result. Ask for "customer revenue" and get three different answers depending on which join path you picked, all of them defensible, only one of them right.

This is the layer where naive text-to-SQL systems quietly produce wrong-but-plausible results — the query runs, returns numbers, and nobody notices anything is off until someone cross-checks against a report they trust. That failure mode is worse than an error message, because an error at least gets investigated.

Layer three: naming and semantic drift

The third wall is the one that's hardest to explain to anyone who hasn't lived in enterprise data — the gap between what a business user says and what the schema calls it. "Revenue" might mean net_amt in one table and gross_txn_val in another, and neither name tells you which one the finance team actually means when they say "revenue" in a meeting. Column names drift from the vocabulary people actually use, sometimes because of legacy system naming conventions, sometimes because different teams built different parts of the schema at different points with different conventions.

This is a mapping problem, not a language problem, and no amount of LLM sophistication resolves it on its own — the model can't infer a business definition that was never written down anywhere.

What's actually worked: a semantic layer

The approach that's moved the needle most for us is building an explicit semantic layer — a maintained mapping between business terminology and the underlying schema, sitting between the natural language query and the retrieval/generation steps. Instead of asking the model to infer that "revenue" means net_amt in this context, that mapping is defined once, by someone who actually knows the data, and the pipeline consults it rather than guessing.

Practically, this means the NLQ pipeline isn't just "user question → retrieval → SQL generation." It's closer to: user question → semantic layer lookup for business terms → schema retrieval scoped to what the mapping resolves to → SQL generation informed by both. The semantic layer doesn't replace retrieval or generation, but it constrains both — it narrows what "revenue" could plausibly mean before the model ever has to guess.

The honest caveat here is that this only works as well as the semantic layer is maintained. It's not a model problem you solve once; it's an ongoing curation problem, and it doesn't fully cover the long tail. Ambiguous terms with genuinely multiple valid interpretations still need a clarification step rather than a confident guess — and we're still figuring out where that clarification should happen in the flow. Should the system ask the user? Pick the most common interpretation and flag it? Show multiple interpretations at once? We don't have a settled answer yet.

Where this leaves us

None of these three layers are fully solved, and I'd be skeptical of anyone claiming they are for a schema of real enterprise size. Retrieval handles table selection reasonably well. Join resolution is improving but still produces confidently wrong answers often enough to matter. Naming and semantic drift is the layer that most depends on human-maintained context rather than model capability — and that's probably not going away, because business meaning isn't something you can fully derive from a schema, no matter how good the model gets at reading one.

About the Author

Written by Manikandan

Software Engineer at DataBrain, where we build embedded analytics for B2B SaaS products. I write about the engineering behind enterprise analytics—tenant isolation, SQL generation, AI guardrails, security, and the product architecture required to make customer-facing analytics trustworthy.

If you found this article useful, consider following me here on Medium.

If your team is evaluating embedded analytics vendors or deciding whether to build analytics in-house, check out what a real proof of concept with DataBrain looks like.