What Is NL2SQL? Natural Language to SQL Explained

NL2SQL, short for natural language to SQL, is the process of translating a plain-language question into a SQL query. A user asks “What was net revenue by region last quarter?” and the system generates a query that a database or cloud data warehouse can execute. NL2SQL is also called text-to-SQL; both names describe the translation mechanism, not whether the resulting answer is correct for the business.

What is NL2SQL?

Natural language to SQL is a software capability that maps a request written in ordinary language to a structured SQL query. It sits between a person and a relational database or warehouse. The person expresses intent; the system identifies the relevant tables, fields, filters, aggregations, and joins; the database executes the generated query.

For example, “Show monthly active customers in Canada for the last six months” might become a query that counts an approved customer identifier, filters a country field, groups by month, and applies a date range. That sounds straightforward until the schema contains three customer tables, two date fields, and no definition of “active.” NL2SQL can solve the syntax and still miss the meaning.

This is why NL2SQL is narrower than conversational BI. Conversational BI may use SQL generation, but it also carries context across follow-up questions, asks for clarification, creates charts or workbooks, and keeps the answer within governed analytics workflows. NL2SQL is one component inside that larger system.

How natural language to SQL works

A basic NL2SQL pipeline has six steps:

1. Receive the question. The system identifies the requested measure, grouping, filter, and time range from the user's words.
2. Retrieve context. It selects relevant schema metadata, table descriptions, example queries, or semantic definitions rather than sending an entire warehouse catalog to the model.
3. Plan the query. The model maps the request to available entities, fields, joins, and SQL operations. An ambiguous request should trigger a clarification instead of a guess.
4. Generate and validate SQL. The system checks syntax, referenced objects, read-only policy, query cost, and other safety rules before execution.
5. Execute with the user's identity. The warehouse runs the query under enforced role, row, and tenant restrictions—not under whatever permissions the model happened to include.
6. Return the result and its lineage. The user sees the answer plus the metric, filters, time range, and query path needed to inspect it.

The warehouse remains the storage and compute layer. NL2SQL does not replace Snowflake, BigQuery, Redshift, or Databricks; it creates a query for the warehouse to run.

Why raw NL2SQL fails on business questions

A database schema describes columns and types. It usually does not say whether revenue is gross or net, whether refunds belong in the current period, which event makes a customer active, or which join preserves the grain of an order. Those are business definitions, and a language model cannot recover them reliably from names such as amount, status, and created_at.

The failure is subtle because the generated SQL can parse, run, and return a plausible table. A bad join may double-count revenue. The wrong date field may shift bookings between quarters. A missing tenant predicate may return another customer's rows. Syntax tests catch none of those errors.

Raw generation also makes repeated answers unstable. If the model chooses among several plausible tables and formulas on each request, two paraphrases of the same question can produce different numbers. The chat-with-your-data guide covers how this failure spreads when natural language becomes the main interface for nontechnical users.

Governed NL2SQL uses a semantic layer

A semantic layer defines metrics, dimensions, entities, join paths, and access rules once. Instead of asking a model to invent net_revenue from raw tables, the NL2SQL workflow can map the user's request to a certified metric and valid dimensions. The platform then compiles that governed request into warehouse-specific SQL.

This changes the model's job. It still interprets language and ambiguity, but it chooses from reviewed business concepts rather than rebuilding metric logic for every prompt. Permissions can be applied before query generation, and the result can point back to a named definition a reviewer can inspect.

Cube is the agentic analytics platform built on a semantic layer. Its AI context layer supplies agents with governed metrics, business concepts, permissions, and lineage at query time. The honest tradeoff is modeling investment: data teams must define the business before the model can answer from it. In return, the query comes from logic the team owns rather than a fresh guess.

How to evaluate NL2SQL in production

Do not grade an NL2SQL system only by exact query match. Two different SQL statements can return the same correct answer, while a query that resembles a reference can still violate permissions or use the wrong business definition.

Use the grounded-answer test instead: can an AI agent answer a real business question on this model, return the right number, under the asker's permissions, traceable back to the definition that produced it?

Test that question with cases that expose real failure modes:

• Ask the same question with several paraphrases and verify the metric definition stays fixed.
• Use two roles or tenants and confirm each receives only permitted rows.
• Try an ambiguous term and check that the system asks for clarification.
• Include joins with different grains and verify the result is not duplicated.
• Inspect the named metric, filters, time range, compiled SQL, and model version behind the answer.
• Submit an expensive or destructive request and confirm guardrails stop it before execution.

If agents need to discover and query those governed definitions programmatically, an analytics MCP server exposes the model as tools with permissions and traceability. MCP does not replace SQL; it gives the agent a governed interface that can ultimately compile to SQL without making free-form SQL generation the trust boundary.

NL2SQL vs. agentic analytics

NL2SQL performs a translation: question in, query out. Agentic analytics covers a broader workflow in which an agent can plan an analysis, select governed metrics, run several queries, ask follow-up questions, explain a result, and create a reusable analytics artifact. The agent may use SQL internally, but its job is not finished when a query compiles.

That distinction matters across both internal and embedded analytics. Internally, a generated query may inform a finance or product decision. Embedded in a software product, the same mechanism answers on behalf of a customer and must enforce tenant isolation under concurrent use. In both contexts, NL2SQL is useful when it operates inside governed analytics architecture. By itself, it is a syntax shortcut with no guarantee that the number means what the user asked.

Methodology

This explainer treats NL2SQL and text-to-SQL as synonyms and separates the translation task from the larger conversational and agentic analytics systems that may use it. The evaluation criteria are editorial judgments based on production failure modes: semantic correctness, permission enforcement, stability across paraphrases, query safety, and traceability. Readers should rerun the grounded-answer checks with their own metrics, schemas, roles, and warehouse workloads.