The Text-to-SQL Problem

Every product manager who has ever seen an LLM writes the same thing on a whiteboard:

User question → LLM → SQL query → Database → Answer

It reads like magic. A user types "how much did we make in July?" and an intelligent system translates that to a query, runs it and returns a number. No SQL knowledge required. No analyst in the loop.

The problem is that this pipeline breaks quietly and often. The LLM writes SQL that runs cleanly, returns a number, and confidently reports it back to the user. The number is wrong. Sometimes the number is wildly wrong. Sometimes it is off by a rounding error you would never spot without knowing the correct answer already.

This is the text-to-SQL problem. It is the single biggest reason enterprises have been slower to adopt AI over their internal data than early demos suggested they would be.

The four ways it breaks

1. The LLM invents columns. You ask about "monthly recurring revenue" and the LLM writes a query joining a table it has never seen with a column called mrr that does not exist. The query fails, or worse, the LLM keeps trying variants until one runs but returns a nonsense number.

2. The LLM picks the wrong table. You have three tables that could plausibly answer a revenue question: orders, invoices and payments. Each captures a slightly different slice of the truth. The LLM picks one, often the one that sounds most obviously "revenue-shaped", and gets a number that answers a subtly different question than the one asked.

3. The LLM joins wrong. Enterprise schemas have twenty tables that all reference customer_id, but the correct join path to answer a specific business question involves a chain of intermediate tables the LLM has no way to discover from the schema alone. It picks the shortest join. The number that comes back is real but semantically meaningless.

4. The LLM ignores access controls. Your data warehouse has row-level security preventing users from seeing customers outside their region. The LLM writes SQL that bypasses that security because it does not know it exists. Congratulations, your AI feature just leaked customer data.

Why more schema does not help

The intuitive fix is more context. Give the LLM the schema. Give it the ERD. Give it example queries. Give it documentation. Give it everything.

This helps at the margin. It does not solve the problem. The reason is that the schema is the syntax of your data, not its meaning. Even a perfectly documented schema does not tell the LLM which of your three revenue tables to trust, or what your business specifically means by "monthly recurring revenue" (does it count trials? proration? one-off addons? annual contracts amortised?).

The bridge between what a user asks and what the data actually means is not something the LLM can invent. It has to be modelled. That modelling is what a semantic layer does, and the rest of this course is about how to do it well.

What this course is not

This course is not a SQL course. If you need SQL fundamentals, take SQL Fundamentals first. This course assumes you can read SQL and understand joins.

This course is not a data engineering course. We touch on data quality, but the primary lens is how to make data trustable by LLMs, which is a specific slice of a much broader discipline.

This course is not tool-agnostic. We use dbt Semantic Layer as the primary teaching tool because it has the largest enterprise footprint in 2026, with Cube shown alongside for context. The concepts transfer to LookML, MetricFlow, AtScale and MicroStrategy Semantic Cloud, but the hands-on work is dbt-first.

Where you should land by the end

You should be able to sit in a technical interview for an AI engineering role, someone asks you "how would you put an LLM on our data warehouse without it hallucinating?" and you can walk them through a complete answer: model the semantic layer, expose it via MCP, wire the LLM to metric queries not SQL, add observability, version metric definitions. That is what "grounded on enterprise data" actually means and it is the discipline this course teaches.

Key Takeaway

Naive text-to-SQL pipelines fail four ways: invented columns, wrong table choice, wrong joins and ignored access control. More schema in the prompt does not fix any of them because the schema is syntax, not meaning. Bridging the gap requires modelling — and that modelling is what a semantic layer does.