Write a SQL query from your schema and a plain-English question

You are a senior data analyst who writes correct, readable SQL.

Database: [ENGINE AND VERSION, e.g. PostgreSQL 16, BigQuery, SQLite]
Schema (only the tables that matter):
```
[PASTE CREATE TABLE STATEMENTS OR TABLE: COLUMN (TYPE) LISTS]
```
Notes about the data: [e.g. "orders.status can be 'paid', 'refunded', 'cancelled'"; "timestamps are UTC"]

Question: [YOUR BUSINESS QUESTION IN PLAIN ENGLISH]

Before writing SQL:
1. Restate the question as a precise definition (what counts, what time range, what grouping).
2. List any assumptions and ambiguities. If an ambiguity would change the answer a lot, ask me before continuing.

Then:
3. Write one query using only the tables and columns in the schema. Use CTEs for readability and comment each step.
4. Explain how the query handles NULLs, duplicates and time zones.
5. Give 2 sanity checks I can run (e.g. a total that should match a known number, a row count).

Never invent table or column names. If something needed is missing from the schema, say what is missing.

Example (excerpt):
Definition: Monthly revenue = sum of orders.amount where status = 'paid', grouped by calendar month in UTC, for 2026.
Assumption: refunded orders are excluded entirely.

WITH paid AS (
  -- keep only paid orders from 2026
  SELECT date_trunc('month', created_at) AS month, amount
  FROM orders
  WHERE status = 'paid' AND created_at >= '2026-01-01'
)
SELECT month, SUM(amount) AS revenue FROM paid GROUP BY month ORDER BY month;

Sanity check: the sum of all months should match the 2026 total in your finance dashboard.

When to use it

Use this prompt when you know what you want to ask your data but not exactly how to write the query, or when you want a second pair of eyes on a query with tricky joins, date logic or window functions. It is aimed at analysts, product managers and developers who work with a database but do not write complex SQL every day.

How to customize it

• [ENGINE AND VERSION] matters because date functions, string functions and limits differ between PostgreSQL, MySQL, BigQuery, Snowflake and SQLite.
• [SCHEMA] should include only the relevant tables, with column types. CREATE TABLE statements work best because they include keys.
• [NOTES ABOUT THE DATA] captures business rules that the schema cannot show: allowed status values, soft deletes, test accounts, time zones.
• [YOUR BUSINESS QUESTION] can be informal. The first step turns it into a precise definition you can approve.

Why it works

The most common failure of text-to-SQL is not syntax but meaning: the query runs but answers a slightly different question. Asking the model to restate the question as a definition and to list assumptions before writing SQL surfaces those differences early. Permission to stop and ask about large ambiguities prevents a confident wrong answer.

Grounding the model in the pasted schema, with an explicit ban on inventing names, reduces hallucinated columns. Comments and CTEs make the query reviewable by a human, and the sanity checks give you a quick, independent test of the result. Our article on how AI data analysis tools work explains the same pattern inside commercial tools.

Tips and variations

• Run generated queries on a read-only connection or a copy of the data first.
• Do not paste real customer data; the schema and a few fake example rows are enough.
• Add “Optimize for a table with about [N] rows” to get index and performance advice.
• Ask for the same query in a second dialect if you are migrating between databases.
• If the result looks wrong, paste the first rows of the output back and ask the assistant to explain the discrepancy.