Querying a database in natural language (NL to SQL)
Querying a database in natural language means typing a plain question and getting the answer a SQL query would return, without writing the SQL. The technique is called NL to SQL, or text-to-SQL: an AI model turns the question into a query, the system runs it and returns the result. It gets things right when it knows the business rules, not just the tables.
What NL to SQL is
Almost all company data lives in a relational database: the ERP database, the payroll system, the online store. Getting an answer out of it takes a SQL query, the language those databases speak. Whoever knows SQL becomes the bottleneck, and whoever needs the answer waits.
NL to SQL (natural language to SQL, also called text-to-SQL) automatically turns a question written in everyday language into that query. Someone types "which customers bought less this quarter than last quarter", the system generates the matching SQL, runs it against the database and returns a number, a table or a chart.
The idea is old. Early attempts relied on hand-written rules and broke on any change in phrasing. Today's language models changed that: they write correct SQL for well-phrased questions over well-named schemas. The hard part now is making sense of a real company database.
When this capability ships inside an analytics tool, with charts, dashboards and access control, it usually goes by the name conversational BI.
Why it works in the demo and fails on the real database
Every NL to SQL demo runs on a sample database with tables named customers, orders and products, clearly named columns and a handful of relationships. In that setting the AI is right almost every time.
A real company database is a different animal:
- Cryptic names. ERP databases often hold hundreds of tables with abbreviated or coded names inherited from old versions of the system. The column with the invoice amount may carry a name only the person who deployed it understands.
- Rules that are not in the schema. Is "revenue" gross or net of returns? Do canceled orders count? What about sales between branches? Those rules live in people's heads and in old reports, not in the tables.
- Ambiguous questions. "How much did we sell in September" could mean order date, invoice date or payment date. Each choice gives a different number.
- Misleading relationships. Joining two tables on the wrong column duplicates rows and inflates the total without raising a single error.
The main risk is not a failed query. It is a query that runs, returns a plausible number and nobody notices it is wrong. An AI that only sees table names writes convincing SQL over columns it does not understand. On a real database, what decides answer quality is the business context the AI gets, more than the model behind it.
| Approach | Who runs the SQL | Business rules | Control and audit | Makes sense for |
|---|---|---|---|---|
| Pasting the schema into a general AI chat | You copy the SQL and run it yourself | Only what you explain in the chat | No record of what was queried; the schema goes into the chat | People who already know SQL and want a quick draft |
| A text-to-SQL library wired in by your team | The application your team built | Whatever your team codes and maintains | Depends on how it was built | Companies with a dedicated data engineering team |
| Conversational BI with a semantic layer | The platform, in read-only mode | Glossary, targets and KPIs kept in the platform | Write blocking and a log of every question and SQL statement | Managers who need answers without knowing SQL |
A comparison of approaches, not of products. Reviewed on October 16, 2026.
What makes an answer trustworthy
Three things separate an answer you can rely on from one that merely looks good.
The first is a semantic layer: a glossary that maps business terms to the right tables, columns and filters. It says what "revenue" means at that company, which table holds the customer master, which filter separates a closed sale from a quote, and which targets and KPIs exist. Building it takes work and someone who knows both the system and the business. Without it, the AI guesses.
The second is transparency. If the tool shows the generated SQL and the reasoning behind it, someone who knows the business can check how the number was built. An answer that does not show where it came from cannot be checked.
The third is testing against known numbers. Before rolling it out, ask questions the team already knows the answer to (last month's revenue, the count of active customers) and compare. Where the numbers differ, fix the glossary and try again.
Security: reading the database without putting it at risk
Giving an AI access to a production database is unnerving, and rightly so. The baseline precautions:
- Read-only, twice over. The tool should block write commands before they run, and the database should get a credential with query permission only. The second lock is the one that holds if the first one slips.
- No open ports. For databases inside the company network, an agent on that network that opens an outbound connection keeps the database off the internet.
- Log everything. Every question and every SQL statement should be recorded, so the company can review what was queried and by whom.
- Permissions per person. Payroll and margin by customer should not show up for everyone.
- Privacy law. Decide which tables and columns with personal data stay out of reach, and document the processing in the company's privacy review (LGPD in Brazil, GDPR in Europe).
NL to SQL beyond English
Current language models handle Portuguese and other major languages well. The difficulty is each company's own vocabulary: industry shorthand, internal acronyms, terms that shift meaning from one sector to the next and sometimes between two companies in the same sector.
That is one more reason for the semantic layer. Once the glossary records what a term means at that company, the question lands on the right query whatever language it is asked in. Dates, currency and decimal separators also need to come out right for the local format, in the answer and not only in the question.
How Entendo does it
Entendo is Sozo Data's conversational BI platform. You ask in Portuguese or English and get the answer as a number, table or chart, with the generated SQL and the reasoning visible for checking.
- It connects to PostgreSQL, MySQL, SQL Server, Oracle, Firebird and ClickHouse, plus Google Sheets, CSV and Excel. If your database is not on the list, we build the connector on request.
- It blocks write commands before they run and logs every question and every SQL statement for audit. We recommend a read-only database credential.
- For databases inside the company network, Entendo Gateway opens an encrypted outbound connection. No inbound port or IP allowlisting is needed, and the database credential stays on the company network. Query results go up to the platform.
- The semantic layer holds the glossary, targets and KPIs. Building it with your team is the core of assisted onboarding, billed separately.
- Every release runs through a suite of 128 NL to SQL test cases.
If the database you want to query sits behind an ERP, see conversational BI on your ERP database. For the full product, see the Entendo page.