Text to SQL: Natural Language to SQL Query Generator That Runs the Query
Ask in plain English. Agentsql reads your schema, writes SQL in your database's own dialect, runs it read-only, and shows you the query it ran.
PostgreSQL · MySQL · Snowflake · BigQuery · read-only · Last updated August 2026
Ask your data a question:
Writing SQL… Running (read‑only)… SQL Agentsql wrote
▋
Click a question. Agentsql writes the SQL, runs it read-only, and answers.
Direct answer
Text to SQL converts a question written in plain English into a runnable SQL query. A tool reads your database schema, generates SQL for your specific engine, and returns the result. The part that decides whether it is useful is not the generation, which modern language models handle well, but whether you can see the query afterward: a number without its query is an unverifiable claim about your own business. Agentsql connects read-only to PostgreSQL, MySQL, Snowflake and BigQuery, writes SQL against your real tables and columns in that engine's own dialect, runs it, and shows the SQL beside every answer. Dialect matters more than most guides admit. DATE_TRUNC takes its two arguments in opposite orders in BigQuery and Snowflake, so a single generic SQL string cannot answer "revenue by month" on both.
›_ how does text to sql work
Four steps, and the order of the first two is the whole game.
Every tool in this category does something like this. What separates them is whether step one happens at all, and whether step four is visible to you.
01
Read the schema
Agentsql introspects your tables, columns, types and relationships on connection. This is what stops the generator from inventing a column called revenue when yours is called total_amount.
02
Generate for your dialect
The question is turned into SQL written for the engine you actually connected, using that engine's functions and quoting rules rather than a generic approximation of SQL.
03
Run it read-only
The query executes through a least-privilege connection that holds SELECT and nothing else, so no generated statement can write, update or delete, whatever it happens to say.
04
Show the SQL
You get a chart, a table and a one-line answer, with the exact query displayed next to it. Read it, copy it, or hand it to an analyst to check the logic.
›_ natural language to sql, the part that breaks
The same function takes its arguments backwards in BigQuery and Snowflake.
Read from both vendors' current documentation on 24 August 2026. This is why a dialect-blind generated string is not a small problem.
BigQuery documents DATE_TRUNC(date_value, date_granularity). Snowflake documents DATE_TRUNC(date_or_time_part, date_or_time_expr). Same name, same two arguments, opposite order. MySQL does not have the function at all and needs DATE_FORMAT instead. So DATE_TRUNC('MONTH', created_at) is correct Snowflake, a type error in BigQuery, and meaningless in MySQL.
Group revenue by month and you have written close to the most common business question there is. It is worth being blunt about what that means: a generator that does not know which engine it is writing for cannot answer the most common question in analytics without getting it wrong somewhere. Here is the same question, written four ways.
| Engine | Truncate to month | Join two strings | Quote a reserved name | Identifier case |
|---|---|---|---|---|
| PostgreSQL | date_trunc('month', created_at) | first_name || ' ' || last_name | Double quotes: "Order" | Unquoted names fold to lower case |
| MySQL | DATE_FORMAT(created_at, '%Y-%m-01') | CONCAT(first_name, ' ', last_name) | Backticks: `Order` | Table name case follows the host filesystem |
| Snowflake | DATE_TRUNC('MONTH', created_at) | first_name || ' ' || last_name | Double quotes: "Order" | Unquoted names fold to UPPER case |
| BigQuery | DATE_TRUNC(created_at, MONTH) | CONCAT(first_name, ' ', last_name) | Backticks: `project.dataset.Order` | Identifiers are case sensitive |
The concatenation column hides a nastier failure than the date one. In MySQL, || is the OR operator unless the server runs with PIPES_AS_CONCAT set, so a Postgres-style concatenation does not error in MySQL. It silently evaluates two strings as booleans and returns a number. That is the kind of bug that reaches a slide deck.
›_ where generated sql goes wrong
Five ways a generated query returns the wrong number, and what actually prevents each one.
Notice that only three of the five are fixable by better generation. The other two are fixed by design decisions: showing the query, and holding a read-only credential.
| Failure | Why it happens | What prevents it |
|---|---|---|
| It invents a column that does not exist | A generator working from the question alone has to guess that revenue lives in total_amount rather than amount, gross, or price_cents. Guessing wrong produces a query that fails loudly, which is the good case. | Read the live schema first. The generator should be writing against your real table and column names before it writes a single clause. |
| It joins on the wrong key | Two tables often have several plausible join paths. Orders to customers might go through customer_id, billing_account_id, or a membership table. Each returns a different number and none of them errors. | Foreign keys and relationships have to come from the schema, and the finished SQL has to be visible so a person can check which path it took. |
| It writes the wrong dialect | DATE_TRUNC takes its arguments in the opposite order in BigQuery and Snowflake, and MySQL has no DATE_TRUNC at all. A string written for the wrong engine is not slightly wrong, it does not run. | The tool has to know which engine it is talking to and generate for that dialect specifically, not for a generic idea of SQL. |
| It answers a different question than you asked | Ambiguity is the real problem. "Revenue last month" could mean orders placed, orders shipped, or payments captured, and could include or exclude refunds, tax and canceled orders. The SQL will be valid either way. | This one cannot be solved by better generation. It is solved by showing the query, so the person who knows the business can read the WHERE clause and correct it. |
| It quietly changes your data | A generated statement is still a statement. An UPDATE or DELETE produced by a model that misread the request runs exactly as well as a SELECT does. | Connect with a least-privilege read-only account so the credential itself cannot write, rather than relying on the model to choose not to. |
The fourth row is the one that decides whether this technology is worth adopting. Syntax errors are cheap because they announce themselves. A query that runs cleanly and quietly counts canceled orders as revenue is expensive, and no amount of model quality removes that risk, because the model cannot know your company's definition of revenue. It can only show you which definition it used. That is the argument for making the SQL visible by default rather than hiding it behind a chart.
›_ choosing a text to sql tool
Six questions to ask a vendor, in the order that matters.
Every one of these is answerable in a trial. None of them requires you to trust a benchmark score measured on somebody else's database.
Does it show the SQL it wrote?
This is the single most important question. A tool that returns a number without the query is asking you to trust an unverifiable claim about your own business.
Does it read your live schema?
Schema-blind generation is where wrong table names and invented columns come from. The tool should introspect your database on connection.
Does it run the query, or just print it?
Most generators hand back a string and leave you to paste it into a client. That saves typing, not time. Running it read-only and returning the result is the difference.
Is the connection read-only?
Ask what privileges the credential actually holds. Read-only should be enforced by the grant, not by the prompt.
Does it generate for your exact engine?
Postgres, MySQL, Snowflake and BigQuery disagree on date truncation, string concatenation and identifier quoting. Generic SQL fails on at least one of them.
What happens when it is not sure?
A good tool asks or shows its assumption. A bad one picks silently, and you find out a quarter later that refunds were never excluded.
One more, less obvious than the six above: ask what the tool costs when a team actually adopts it. Several vendors meter AI questions rather than seats, and an allowance sized for a demo runs out in the first fortnight of real use. ThoughtSpot, for example, caps its AI analyst at 25 questions per user per month on seat pricing, which the ThoughtSpot pricing breakdown works out at $2.00 a question. Our pricing is a flat monthly figure with no question cap, which we mention here because the cap is the thing people discover late.
›_ who asks a database questions in plain english
Four people who get their afternoon back.
Founders
You know the business well enough to spot a wrong number instantly, and you do not want to wait two days for a pull that takes four lines of SQL. More for founders.
Analysts
The queue of routine pulls stops arriving, and when a generated query is wrong you can read it and say why in seconds. More for analysts.
Ops teams
Questions that arrive mid-incident do not fit a dashboard someone built last quarter. More for ops.
Product managers
Feature questions are one-offs by nature, which is the worst possible fit for a pre-built report. More for product.
Worth saying plainly, because the marketing in this category tends not to: text to SQL does not replace a data team. It removes the routine half of their inbox. The questions that need a definition argued out, a pipeline fixed or a model built still need a person, and those are the questions worth an analyst's time in the first place.
›_ frequently asked
Text to SQL questions, answered.
How does text to SQL work?
A text to SQL tool reads your database schema, then uses a language model to turn your plain-English question into a SQL query written for your specific engine. Agentsql runs that query read-only against your connected database and returns a chart, a table and a one-line answer, with the generated SQL shown beside the result so you can verify it.
Can AI write SQL queries?
Yes, and reliably so when it can see your schema. The accuracy problem is rarely SQL syntax, which models handle well. It is knowing that revenue lives in total_amount, that orders join customers through customer_id, and that canceled rows must be excluded. Schema access solves the first two; showing the query solves the third.
Can AI write complex SQL queries?
It can write multi-table joins, window functions, CTEs and nested aggregates without difficulty. Complexity of syntax is not the limit. The limit is ambiguity in the request, because a complex query has more places for a wrong assumption to hide, which is exactly why the SQL needs to be readable before you act on the number.
How accurate is text to SQL?
Accuracy depends almost entirely on whether the tool reads your real schema and generates for your real engine. Published benchmark percentages are measured on public academic datasets, not on your warehouse, so treat them as marketing rather than a forecast. The practical answer is to verify: read the query it wrote before you trust the number.
What is natural language to SQL?
Natural language to SQL, sometimes written NL2SQL or NLP to SQL, is the same idea as text to SQL: converting a question written the way a person speaks into a runnable SQL statement. The terms are used interchangeably in industry, while academic papers tend to prefer NL2SQL.
How do I convert text to a SQL query?
Connect the database first, then ask the question. The order matters, because a generator that has not read your schema is guessing at table and column names. With Agentsql you connect read-only, type the question in plain English, and get the SQL plus the answer it returns. No schema modeling project comes first.
Is text to SQL safe to point at a production database?
It is if the connection is read-only at the database level. Grant a least-privilege user with SELECT and nothing else, so a generated statement physically cannot write, update or delete regardless of what the model produces. Agentsql connects read-only by design. Never give a query tool a credential that can write.
Does text to SQL work with my own database schema?
It should, and a tool that does not is the wrong tool. Agentsql reads your tables, columns and relationships on connection, so the SQL it writes uses your real names and the correct join paths. Generation against a generic schema is where most incorrect answers come from.
Which databases does Agentsql support?
Four: PostgreSQL, MySQL, Snowflake and BigQuery. Each one gets SQL generated for its own dialect rather than a generic string, which matters more than it sounds. DATE_TRUNC alone takes its arguments in opposite orders in BigQuery and Snowflake, and MySQL does not have the function at all.
Do I still need an analyst if I use text to SQL?
Yes, and the good version of this technology assumes so. What changes is what the analyst spends the day on. Routine pulls stop arriving in their queue, and their job shifts toward defining what the numbers mean and reviewing the queries behind the ones that matter. That is why the generated SQL being readable is a feature for analysts, not just for beginners.
›_ how it works
›_ connect your database
›_ compare and price
Ask the question. See the SQL.
Connect read-only to Postgres, MySQL, Snowflake or BigQuery and get an answer with the query beside it.