How to Generate SQL Queries from Plain English (Without Breaking Production)

How do you generate SQL from plain English without risking your production database? Treat the AI as a translator, not an oracle. Write the business question with its grain and filters, paste your table schema and dialect, ask for a draft query with a plain-English explanation, review every join and WHERE clause, then run it on a read-only account or a replica before anything touches real data. The workflow is English question, schema grounding, SQL draft, review, test, ship. Five steps, repeatable, tool-agnostic.

The five-step loop: clarify the question → ground in schema → generate SQL → review for safety → test on a copy. Tools like Text2SQL.ai, Vanna.ai, Defog SQLCoder, Google AlloyDB AI, Snowflake Cortex Analyst, and Databricks Genie specialize in this. General assistants (ChatGPT with GPT-5.x, Claude Opus 4.x, Gemini 2.5 Pro) work well when you paste the schema into the prompt. The bottleneck is never the model. It is the prompt context and the review discipline.

The Translation Workflow: English, Schema, SQL, Validation

Most people who need data from a database do not write SQL every day. They know what they want to know (how many repeat buyers did we have last month?) but not how to express it in a query language. AI bridges that gap, but only when you treat it as a translator that needs context, not a fortune teller that reads minds.

The workflow has five stages, and every section of this guide maps to one of them:

1. Clarify the question in plain English with metric, grain, filters, and time window.
2. Ground the model in your actual schema: tables, columns, relationships, dialect, sample rows.
3. Generate a draft SQL query with a plain-English explanation from the AI.
4. Review the SQL for joins, WHERE clauses, aggregation, grain, and destructive keywords.
5. Test on a copy or read-only account, validate row counts, then ship to production.

Each step takes seconds once you have the habit. Skipping any step is where things break. The prompt card at the end of this post encodes all five steps into a copy-paste template.

Who This Is For (and Who Still Needs an Analyst)

If you are a marketer who wants to know which campaigns drove the most orders, a product manager checking feature adoption by cohort, a founder pulling a quick revenue number for an investor update, or an operations lead tracking ticket aging, this workflow is for you. You know the business question. The AI knows SQL syntax. Your job is to connect the two safely.

If you are running multi-source financial reports, touching production data with UPDATE or DELETE statements, or building a pipeline that other people depend on, you still need a data engineer or analyst. AI is excellent for ad-hoc reads and exploration. It is dangerous for anything that mutates data without a human who understands the full context reviewing every line.

The line is simple: SELECT is your playground. INSERT, UPDATE, and DELETE need a human who knows the schema by heart.

Step 1: Clarify the Business Question Before You Touch a Tool

The number one reason AI SQL comes back wrong is not a model limitation. It is a vague prompt. "Show me our sales" could mean revenue by day, units sold by product, top customers by spend, or a dozen other things. The model will pick one. It might not be the one you meant.

Before you type anything into a tool, write down these five elements:

This takes 30 seconds and eliminates most "the query returned something weird" problems. If you cannot fill in all five, you are not ready to generate SQL yet. Go talk to whoever asked the question.

Step 2: Ground the Model in Your Data Model

AI models do not know your database. They do not know that orders.status stores 'paid' and 'pending' as lowercase strings, or that order_items joins to orders on order_id, or that your timestamps are in UTC. You have to tell them.

The minimum context the model needs:

• Database dialect: PostgreSQL, MySQL, SQLite, SQL Server, BigQuery, Snowflake. SQL syntax differs enough that the wrong dialect produces queries that will not run.
• Table definitions: CREATE TABLE statements are ideal because they include types, primary keys, and foreign keys in one block. A compact column list works if you also describe relationships.
• Relationships: Which columns join to which. "orders.customer_id references customers.id" is enough.
• Sample rows (2-3): Helps the model understand data shapes, enum values, and nullability.
• Known quirks: Soft-deleted rows (look for deleted_at IS NULL), timezone storage, status enum values, case sensitivity.

If you skip schema grounding, the model will invent plausible column names that do not exist in your tables. This is the most common failure mode, and it is entirely preventable.

Worked Schema: An Ecommerce Mini Warehouse

Every example in this post uses the same schema so you can follow along. It is a simplified ecommerce database with four tables:

-- Dialect: PostgreSQL

CREATE TABLE customers (
    id          BIGINT PRIMARY KEY,
    email       TEXT NOT NULL UNIQUE,
    name        TEXT,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    country     TEXT
);

CREATE TABLE orders (
    id            BIGINT PRIMARY KEY,
    customer_id   BIGINT NOT NULL REFERENCES customers(id),
    status        TEXT NOT NULL,  -- 'pending','paid','shipped','refunded'
    channel       TEXT,           -- 'web','ios','android','referral'
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
    total_cents   INTEGER NOT NULL  -- order total in cents
);

CREATE TABLE order_items (
    id          BIGINT PRIMARY KEY,
    order_id    BIGINT NOT NULL REFERENCES orders(id),
    product_id  BIGINT NOT NULL REFERENCES products(id),
    qty         INTEGER NOT NULL,
    unit_price_cents INTEGER NOT NULL
);

CREATE TABLE products (
    id           BIGINT PRIMARY KEY,
    sku          TEXT NOT NULL UNIQUE,
    name          TEXT NOT NULL,
    category      TEXT,
    price_cents   INTEGER NOT NULL
);

Key facts for this schema: amounts are stored in cents (multiply by 100 to get dollars), orders.status is a lowercase enum, created_at is in UTC, and a paid order has status = 'paid'. Keep these in mind for the examples below.

Example 1: Revenue Last 30 Days by Channel

Plain-English question

"How much revenue did we make in the last 30 days, broken down by sales channel? Only count paid orders. I want one row per channel with the total revenue in dollars and the number of orders."

Prompt to the AI

Dialect: PostgreSQL
Schema: [paste the CREATE TABLE block above]

Question: Total revenue and order count by channel for the last 30 days.
Only include orders where status = 'paid'.
Revenue should be in dollars (total_cents / 100.0).
One row per channel.
Sorted by revenue descending.

Generated SQL

SELECT
    o.channel,
    ROUND(SUM(o.total_cents) / 100.0, 2) AS revenue_dollars,
    COUNT(*) AS order_count
FROM orders o
WHERE o.status = 'paid'
  AND o.created_at >= now() - INTERVAL '30 days'
GROUP BY o.channel
ORDER BY revenue_dollars DESC;

What to check

• Table and column names match the schema? Yes: orders.channel, orders.total_cents, orders.status, orders.created_at all exist.
• Filter is restrictive enough? status = 'paid' excludes pending, shipped, and refunded. The date filter uses now() - INTERVAL '30 days', which is a rolling 30-day window. Confirm that is what you wanted (not a fixed calendar month).
• Grain is correct? One row per channel, which matches the question. The GROUP BY is on channel only.
• Aggregation is correct? Sum of cents divided by 100 gives dollars. COUNT(*) counts orders, not order items, because the query does not join to order_items. That matches "number of orders."
• No destructive keywords? No DROP, DELETE, UPDATE, or ALTER. Safe to run.

Example 2: Repeat Purchasers and Average Order Value

Plain-English question

"Which customers placed more than one order in July 2026? Show me their email, name, number of orders, and average order value in dollars. Sort by order count descending, top 20."

Prompt to the AI

Dialect: PostgreSQL
Schema: [paste the CREATE TABLE block above]

Question: Customers with more than one order in July 2026 (created_at between
'2026-07-01' and '2026-07-31' UTC). Show email, name, order count,
average order value in dollars. Top 20 by order count descending.
Only include paid orders.

Generated SQL

SELECT
    c.email,
    c.name,
    COUNT(o.id) AS order_count,
    ROUND(AVG(o.total_cents) / 100.0, 2) AS avg_order_value_dollars
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid'
  AND o.created_at >= '2026-07-01'::timestamptz
  AND o.created_at < '2026-08-01'::timestamptz
GROUP BY c.email, c.name
HAVING COUNT(o.id) > 1
ORDER BY order_count DESC
LIMIT 20;

What to check

• Join condition? o.customer_id = c.id is correct and matches the foreign key. No missing join key, no Cartesian product risk.
• Date boundaries? Using >= '2026-07-01' and < '2026-08-01' is the correct half-open interval pattern. It includes all of July 1 through July 31 without timezone surprises.
• Grain? One row per customer (grouped by email and name). COUNT(o.id) counts orders per customer. AVG computes the average order value per customer. This matches the question.
• HAVING vs WHERE? HAVING COUNT > 1 filters after aggregation, which is correct for "more than one order." Putting this in WHERE would fail because COUNT is an aggregate.
• Limit? Top 20 as requested.
• Common mistake to watch for: If the AI had joined order_items to count items instead of orders, COUNT would be too high. The question asked for order count, so the join should stop at orders.

Example 3: Refund Rate by Product Category

Plain-English question

"What is the refund rate for each product category? Show me the total orders, refunded orders, and refund rate as a percentage. Only look at orders from 2026. Sort by refund rate descending."

Prompt to the AI

Dialect: PostgreSQL
Schema: [paste the CREATE TABLE block above]

Question: Refund rate by product category for orders in 2026.
- Total orders = count of orders that include at least one item in that category
- Refunded orders = count of those orders where status = 'refunded'
- Refund rate = refunded / total * 100, rounded to 1 decimal
- Sort by refund rate descending

Generated SQL

WITH category_orders AS (
    SELECT
        p.category,
        o.id AS order_id,
        o.status
    FROM orders o
    JOIN order_items oi ON oi.order_id = o.id
    JOIN products p ON p.id = oi.product_id
    WHERE o.created_at >= '2026-01-01'::timestamptz
      AND o.created_at < '2027-01-01'::timestamptz
    GROUP BY p.category, o.id, o.status
)
SELECT
    category,
    COUNT(*) AS total_orders,
    COUNT(*) FILTER (WHERE status = 'refunded') AS refunded_orders,
    ROUND(
        COUNT(*) FILTER (WHERE status = 'refunded')::NUMERIC
        / COUNT(*) * 100, 1
    ) AS refund_rate_pct
FROM category_orders
GROUP BY category
ORDER BY refund_rate_pct DESC;

What to check

• Double counting? The CTE groups by category, order_id, status so each order is counted once per category. Without this GROUP BY, an order with two items in the same category would be counted twice. This is the most common mistake in this type of query.
• Join chain? orders → order_items → products. Three-table join, both join keys present: oi.order_id = o.id and p.id = oi.product_id. Correct.
• Filter clause? FILTER (WHERE status = 'refunded') is PostgreSQL syntax for conditional aggregation. It counts only rows where status is refunded. More concise and reliable than a CASE expression.
• Numeric division? The ::NUMERIC cast prevents integer division truncation. Without it, 3 / 7 * 100 would give 0 in PostgreSQL integer math.
• Time window? All of 2026, half-open interval. Correct.
• No destructive keywords? Read-only SELECT. Safe.

Pick the Right Tool for Your Situation

There is no single best AI SQL generator. There is the best one for your situation. The decision comes down to three questions: Where does your data live? How often do you need queries? Can you send schema details to a third-party API?

For most readers, the workflow looks like this: start with the ILAA SQL Generator or a general LLM chat for your first few queries. If you find yourself pasting the same schema repeatedly, move to Vanna or a standalone tool that stores your schema. If your data is in a single warehouse (Snowflake, BigQuery, AlloyDB), try the native option first because it already knows your tables and permissions.

Open-source models like Defog SQLCoder deserve special mention for privacy-sensitive environments. SQLCoder is a family of fine-tuned models (7B, 8B, 34B, 70B) built specifically for text-to-SQL. Defog's own SQL-Eval benchmark reports that larger SQLCoder variants outperform general models on join, grouping, ordering, and date tasks. The weights are available via Hugging Face and Ollama under CC BY-SA 4.0, which means you can run them locally with no data leaving your network. For healthcare, finance, or regulated industries, this is often the right answer.

The Awesome-Text2SQL repository on GitHub is a curated index of text-to-SQL papers, datasets (Spider, BIRD), models, and tools. It is the best starting point if you want to compare benchmarks or explore research-grade approaches.

Step 4: Review the SQL Before You Run It

Generated SQL is a draft. Treat it like a pull request from a smart junior developer who occasionally makes confident mistakes. Your job is to catch those mistakes before they hit data. Run through this checklist on every generated query:

This takes about 60 seconds for a typical query. It has caught a hallucinated column, a missing join key, or a wrong grain in roughly one out of every four queries I have tested across models and tools. That is a high enough rate to justify the review every time.

Failure Gallery: Five Ways AI SQL Lies to You

These are the failure modes I have seen repeatedly across ChatGPT, Claude, Gemini, and specialized tools. Each one produces a query that looks correct and runs without errors but returns wrong data. The danger is silent wrong answers, not crash messages.

Every one of these is preventable with the review checklist above. The gallery exists because skipping review is the default, not because the failures are rare.

Step 5: Safety and Permissions for Non-Admins

If you are reading this guide, you are probably not a database administrator. That is fine. You do not need admin rights to run SELECT queries, and you should not have them. Here is how to keep things safe when you are working with AI-generated SQL:

Use a read-only account

The database user that runs AI-generated queries should have SELECT permission only. No INSERT, UPDATE, DELETE, DROP, ALTER, or GRANT. If the account physically cannot modify data, then even a catastrophic AI mistake is limited to a wrong result set, not destroyed data. Ask your database admin (or your hosting provider's dashboard) to create a read-only role for analytics work.

Test on a copy first

If you do not have a read-only replica, wrap exploratory queries in a transaction and roll back:

BEGIN;
SELECT ... ;  -- your AI-generated query
ROLLBACK;

This does not help for SELECT queries (they do not modify data), but it is essential if you ever generate INSERT, UPDATE, or DELETE statements. The transaction lets you see affected row counts before committing.

Use parameterized queries in production code

If the AI-generated SQL will run inside an application (not just in a one-off query window), ask the model to output parameterized placeholders:

-- Instead of: WHERE created_at >= '2026-07-01'
-- Ask for:  WHERE created_at >= ?

Your application binds the actual value at runtime, which prevents SQL injection and makes the query reusable with different date ranges.

Never paste secrets or real customer data into a prompt

Schema definitions (table names, column types) are fine to share. Real customer rows with emails, phone numbers, or payment details are not. If you need sample rows for the AI to understand data shapes, use fictional or anonymized data. If your schema itself is confidential (proprietary table names that reveal business logic), use a self-hosted model like SQLCoder instead of a public API.

Log prompts and generated queries

Keep a log of the English prompt and the generated SQL for every query you run. When a result looks wrong, the log tells you exactly which prompt produced it, so you can fix the prompt or the schema context. This is also useful for building a library of verified queries you can reuse without re-prompting.

Downloadable Prompt Card Template

This is the information-gain artifact of this guide. Copy it, fill it in, paste it into any AI tool, and you will get better SQL on the first try. Every field matters.

-- ENGLISH TO SQL PROMPT CARD
-- Copy this block, fill in your details, paste into your AI tool.

Dialect: [PostgreSQL / MySQL / SQLite / SQL Server / BigQuery / Snowflake]

Question:
[State what you want to know in plain English. Include the metric,
the grain (one row = what?), and any filters.]

Time window: [e.g., last 30 days, July 2026, all of 2026]
Time zone: [e.g., UTC, Asia/Kolkata, America/New_York]

Schema:
[Paste your CREATE TABLE statements here, or a compact column list
with types and relationships. Include 2-3 sample rows if possible.]

Known quirks:
[List anything the model might get wrong: soft deletes, enum values,
case sensitivity, timezone storage, integer division, etc.]

Forbidden operations:
[DROP, DELETE, UPDATE, ALTER, TRUNCATE, GRANT]

Output format:
[SQL query with comments + a 2-3 sentence plain-English explanation
of what the query does]

Safety:
[Require: all identifiers must match the schema. Every JOIN needs an ON
clause. No query should modify data. Parameterize values if this will
run in application code.]

Save this template as a text file, a Notion page, or a snippet in your editor. Every time you have a data question, fill it in and paste it into your tool of choice. The first few times will feel slow. By the fifth query, you will fill it in without thinking, and your AI-generated SQL will be dramatically more accurate.

12-Point Pre-Run Checklist (Print This)

If any box is unchecked, fix the issue before you trust the result. This checklist has a zero-tolerance policy for #8 (destructive keywords) and #11 (account permissions). Everything else is a judgment call based on how much you trust the data.

Next Steps and Related Tools

Now that you have the workflow, here is where to go next:

• Try it now: paste your next business question into the ILAA AI SQL Generator. No signup required.
• Review the output: use the ILAA AI Code Reviewer to catch issues in generated SQL before you run it.
• Related pattern: if you also work with regex, read Generate Regex from Plain English with AI for the same translation workflow applied to pattern matching.
• Code review mindset: the safety principles in AI Code Reviewer Guide apply to SQL review too. Treat generated queries like untrusted code.
• More free tools: browse 20 Free AI Tools You Can Use Without Signing Up for other no-setup workflows.
• Spreadsheet formulas: if your data lives in Excel or Google Sheets instead of a database, the same English-to-formula workflow applies. Look for the ILAA Spreadsheet Formula Generator (coming soon).

FAQ

Can ChatGPT, Claude, or Gemini write SQL from plain English?

Yes. ChatGPT (GPT-5.x family), Claude Opus 4.x, and Gemini 2.5 Pro all generate SQL well when you provide the schema and dialect. The quality depends almost entirely on the prompt context. Paste your CREATE TABLE statements, mention the dialect, ask for an explanation, and the output is usually usable after a quick review.

What is the best free AI SQL generator in 2026?

For a zero-install web tool, the ILAA AI SQL Generator is free with no signup. For privacy-sensitive setups, Defog SQLCoder is open-source and runs locally via Ollama. For schema-aware repeated queries, Vanna.ai trains on your schema and gets better with use. The "best" depends on where your data lives and whether you can send schema details to a third-party API.

How do I make AI-generated SQL safe to run in production?

Three controls: (1) run on a read-only or least-privilege database account that cannot DROP, ALTER, INSERT, UPDATE, or DELETE. (2) Review every generated query against the 12-point checklist in this post before executing. (3) If the query will run in application code, use parameterized placeholders instead of inline values to prevent SQL injection.

What should I include in my prompt to get better SQL?

The five essentials: database dialect (PostgreSQL, MySQL, etc.), table definitions with types and relationships, 2-3 sample rows, known quirks (soft deletes, enum values, time zones), and explicit safety constraints (no destructive keywords, all identifiers must match the schema). Use the prompt card template in this post as your starting template.

What is Text2SQL and how is it different from asking ChatGPT for SQL?

Text2SQL (also called NL2SQL or natural language to SQL) is the research field and product category for tools specifically built to convert English questions into SQL. They differ from general chatbots in two ways: they are schema-aware (you connect your database or paste the schema and they use it as context), and they are fine-tuned or RAG-enhanced for SQL specifically. ChatGPT is a general assistant that can write SQL but does not inherently know your schema. Tools like Text2SQL.ai, Vanna.ai, and SQLCoder specialize; ChatGPT generalizes.

Why does my generated SQL return the wrong row count?

The three most common causes: (1) a missing JOIN condition causing a Cartesian product that multiplies rows, (2) joining to a child table (like order_items) without deduplicating, which counts each parent row once per child, or (3) a WHERE clause that is less restrictive than you intended. Check the join keys, the GROUP BY grain, and the WHERE filters against your expected row count.

Can I use open-source models to generate SQL locally?

Yes. Defog SQLCoder is a family of open-source models (7B through 70B) fine-tuned specifically for text-to-SQL. You can run them locally via Ollama or Hugging Face. Vanna.ai is an MIT-licensed framework that pairs with any LLM (including local models) for schema-aware SQL generation. Both are good choices when data or schema cannot leave your infrastructure.

Which database dialects do AI SQL generators support?

Most tools support PostgreSQL, MySQL, SQLite, SQL Server, Oracle, BigQuery, and Snowflake. Database-native tools (AlloyDB AI, Cortex Analyst, Genie) support their own dialect only. General LLMs can handle most dialects if you specify which one you need. Always state the dialect in your prompt, because syntax for dates, string functions, and conditional aggregation varies significantly across engines.

Last updated 18 August 2026. Tool names and features verified against official documentation and GitHub repositories on that date. Current model names: ChatGPT GPT-5.x family, Claude Opus 4.x, Gemini 2.5 Pro, Defog SQLCoder, Vanna.ai, Text2SQL.ai, SQLAI.ai, Google AlloyDB AI, Snowflake Cortex Analyst, Databricks Genie.