All posts2026-07-06 · 6 min read

Natural Language to SQL: How It Works and Why the Visible Query Matters

A plain-English guide to natural-language-to-SQL: how a question becomes a query, why a read-only, always-visible query is safer, and how PerSight keeps your row data on your machine.

Data is a precious thing and will last longer than the systems themselves.Tim Berners-Lee, 2006

Natural language to SQL means you type a question in plain English — "which customers spent the most last quarter?" — and a tool turns it into a SQL query that runs against your database. It lets people who do not write SQL get answers from their own data, and it lets analysts skip the boilerplate. The idea is simple; the details are where trust is won or lost.

How natural language to SQL works, step by step

Under the hood almost every natural-language-to-SQL tool follows the same four steps. Understanding them makes it obvious which parts are safe and which parts you should be able to inspect.

  • Read the schema: the tool needs your table and column names (the structure), not your rows, to know what can be queried.
  • Generate SQL: a language model turns your question plus the schema into a SQL statement.
  • Run the query: the statement executes against your database and returns rows.
  • Present the result: rows become a table and charts you can read.

Two of these steps decide whether the tool is trustworthy: what gets sent out to generate the SQL, and whether you can see the SQL before it runs.

Why the generated query must stay visible

A language model can be confident and wrong. If a tool hides the SQL and just shows you a number, you have no way to know whether it answered the question you actually asked. A visible, editable query turns a black box into something you can verify: you read what it will do, adjust it if needed, and only then run it.

The safest natural-language-to-SQL answer is one you can read the query for. Verifiability is not a feature bolted on afterwards — it is the whole point.

PerSight shows the generated SQL for every question, explains in plain language what it does, and lets you edit it before running. It only ever generates read-only (SELECT) statements, so a query cannot change or delete your data by design.

The privacy question: does my data go to the cloud?

This is the question most teams should ask first. Many hosted tools send data to a server to work. PerSight is built the other way around: the query runs on your own machine, and only your database schema (table and column names) and your question are sent to the model to generate SQL. Your actual rows never leave your computer. A transparency panel shows you exactly what would be sent before anything leaves.

  • Sent to the cloud: the schema (structure) and your natural-language question.
  • Never sent: your row data — it stays on your machine, where the query executes.
  • Enforced by design: only read-only SELECT queries are generated; writes and deletes are blocked.

Frequently asked questions

Do I need to know SQL? No — you write the question in your own language and PerSight produces the SQL and explains it. Which databases are supported? PostgreSQL and Microsoft SQL Server today. Is it safe to connect a production database? PerSight generates read-only queries and runs them locally under your own credentials, so it can read what you can read and change nothing.

PerSight is a Windows desktop app that turns plain-language questions into verifiable, read-only SQL for your own PostgreSQL or SQL Server database — with your row data never leaving your machine. It is currently in invite-only free beta.

References