NL-to-SQL: query databases in plain language

The problem: the data is there, but you need SQL to see it

Many business questions have an answer in a database, but getting it means writing a SQL query or asking the BI team. The result is request queues, late reports and decisions made on incomplete data.

What NL-to-SQL does

• Interprets a plain-language question.
• Translates it into a SQL query over the connected databases.
• Returns the result without the user needing to know the schema or write code.

Documents and data in the same question

RootNia’s orchestrator connects both document repositories and databases. RAG handles documents and NL-to-SQL handles structured data, so a single question can draw on both.

Example: from question to query

Illustrative example of how it works, not a specific customer.

An operations manager asks: “How many orders were delivered late, by region, in September?” NL-to-SQL identifies the order and delivery tables, builds the query that groups delays by region and filters the month, runs it against the connected database and returns the result as a table — without the user needing to know the schema.

Limits and good practices

• Clear schemas: understandable table and column names greatly improve the translation to SQL.
• Ambiguous questions: “late” can be defined in several ways; the more specific the question, the more reliable the result.
• Permissions: connect NL-to-SQL with read-only database users scoped to what each team should see.

Use cases

• Finance: ad hoc queries on transactions, positions or customers.
• Engineering: operational data and metrics without waiting on an analyst.
• Business teams that rely on manual reports today; see the comparison with manual processing.