SQL Query Builder from Plain English
Describe the data you want in plain English — “top 10 customers by revenue last quarter” — and get working SQL with an explanation of each clause. Give it your schema for accurate table and column names.
Describe the data you want in words — get optimized SQL with an explanation of every clause.
You are a database expert fluent in [DIALECT, e.g. PostgreSQL]. I will describe the data I need in plain English, along with my table schemas. Write the query, then: 1) Explain each clause in one line, 2) Note any assumptions you made about the schema, 3) Suggest the indexes that would speed this up, 4) Flag any edge cases (NULLs, duplicates, timezones). Prefer readable CTEs over nested subqueries. Here is my schema and request:
See what this prompt creates
What this prompt does
SQL is easy to read and surprisingly hard to write correctly — joins, grouping, window functions, and the order clauses actually execute in. This prompt lets you think in questions and get queries: describe what you want, paste your table schemas, and receive working SQL plus a plain-English explanation of what each part does, so you learn while you ship.
How to get the best result
The schema is everything. Paste your CREATE TABLE statements (or a compact description: table names, columns, keys) — without it, the model invents plausible-but-wrong column names. State your dialect: Postgres, MySQL, BigQuery, and SQL Server differ on date functions, quoting, and window syntax. Then verify on a copy of real data before running anywhere important.
Common mistakes to avoid
Never run AI-generated SQL with write permissions (UPDATE/DELETE/DROP) without reading every line — one wrong WHERE clause is a data incident. Default to read-only credentials for AI-assisted querying. And double-check aggregations: the classic AI error is a GROUP BY that silently double-counts through a fan-out join.
Verify it on ten rows before you trust it
The dangerous SQL query is not the one that errors. It's the one that runs cleanly and returns a plausible number that's wrong — a join quietly doubling your revenue, a WHERE clause excluding every customer who never ordered. This prompt's clause-by-clause explanation is your first check, but build a stronger one: ten rows you invented. Sketch a miniature table in the chat (or a scratch database) with rows chosen to be troublemakers — one customer with no orders, one order with a NULL date, one refund that makes a total negative. Run the query. You already know the right answer for ten invented rows, which makes you the only reliable test the query will ever get.
Read the assumptions list the prompt returns as if it were a contract, because it is one. "Assumed orders.status excludes cancelled orders" is the model telling you it made a business decision on your behalf. Half the time it's the decision you'd want; the other half it's how cancelled orders end up in the board report. Correct the wrong assumptions in a follow-up and the regenerated query absorbs the fix — and now the assumptions list doubles as documentation for whoever inherits the query.
Last step, for anything that will run against production data: ask the model to review its own query with EXPLAIN. Paste the query plan back in and say "where will this hurt at ten million rows?" The index suggestions in the original output are generic good advice; advice aimed at your actual execution plan is specific — it will name the sequential scan and the sort that spills to disk. Ten rows of testing, one assumptions check, one query plan. Fifteen minutes that stand between a confident answer and a correct one.
Try these variations
Use it in reverse: paste a legacy query and ask what it does — invaluable for inherited reporting code. For messy string data feeding your queries, the regex explainer prompt cleans inputs first. More in the coding prompts collection.
How to use this prompt
- Copy it — hit the copy button above to grab the raw prompt text.
- Fill the brackets — replace anything in [BRACKETS] with your own details.
- Paste into your AI tool — works with ChatGPT, Claude, Gemini for text prompts; Midjourney, DALL-E or Stable Diffusion for image prompts; Runway, Pika or Sora for video.
- Iterate — tweak one bracket at a time until the output is exactly right.
Frequently asked questions
Do I need to share my database schema?
For accurate queries, yes — table names, columns, and keys. Share structure, not data: CREATE TABLE statements or a schema description contain no actual rows. Never paste real customer data into the chat.
Which SQL dialects does it handle?
Postgres, MySQL, SQLite, BigQuery, Snowflake, SQL Server, and others. Always name your dialect — date functions, string quoting, and window function syntax differ enough to break queries across dialects.
Can it optimize slow queries?
Yes — paste the query plus EXPLAIN output and it will suggest indexes, rewrite joins, and flag fan-out aggregations. It's a strong first pass; your DBA still wins on deep engine-specific tuning.
Is it safe to run the generated SQL directly?
For SELECT queries on non-production data, generally yes after a quick read. For anything that writes data, read every clause first and test on a backup. AI SQL is a draft, not a deploy.
