PromptDev

Write a SQL query from plain English

Hand over the schema and the question, get back a query that uses only your real columns — with its assumptions stated, not smuggled in.

Last updated

Fill in the blanks

Assembled in your browser — nothing you type is stored or sent anywhere.

Your prompt

Write a DuckDB query. Schema (the ONLY tables and columns that exist): orders(id, customer_id, total, created_at) customers(id, name, country, signed_up_at) Question to answer: the five countries with the highest average order value this year Rules: use only the tables and columns above — if the question needs data the schema doesn't have, say so instead of inventing a column. State any assumption you make (how NULLs are treated, what ties do, date boundaries) as comments in the query. Then explain in two sentences what the query does and where it could be slow on a large table.

Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.

Why this prompt works

  • →Declaring the schema as exhaustive is the single biggest fix — without it, models cheerfully JOIN to tables that don't exist.
  • →Assumptions-as-comments puts the judgement calls (NULLs, ties, "this year") where the next reader of the query will actually see them.
  • →The performance sentence catches the accidental full-table scan while the query is still in a chat window instead of a dashboard.

Part by part

the ONLY tables and columns that exist
The strongest available constraint against invented schema. Without it a model produces a query referencing a plausible column that is not there.
say so instead of inventing a column
Names the failure directly. A query against a column that does not exist is at least an error; one against a column that exists and means something else is silently wrong.
State any assumption you make
NULL handling, tie-breaking and date boundaries are where two correct-looking queries return different numbers. Making them explicit puts the decision back with you.
as comments in the query
Keeps the assumptions attached to the SQL, so they survive being pasted somewhere else — which is where a query usually ends up.
where it could be slow on a large table
A performance note before it becomes a problem, which is the cheapest moment to hear it.

Common mistakes

  • Write a SQL query to get the top customers by revenue.

    Without a schema, the query invents table and column names that look right. It runs nowhere, and adapting it is often more work than writing it yourself.

  • Pasting the schema without types or nullability.

    Those determine how the query should handle missing values and comparisons. A nullable column joined without care silently drops rows, which is invisible in the result.

  • Accepting the query without reading the assumptions.

    The comments are where the interesting decisions are — whether a tie takes both rows, whether a date range includes its endpoint. Those change the answer more often than the SQL structure does.

Questions

What should I include in the schema?

Table names, column names, types, nullability, and which columns are indexed. The last one is what makes the performance note meaningful rather than generic.

Why do assumptions belong in comments?

Because the query gets pasted into a dashboard or a script and the surrounding explanation does not travel with it. A comment is the only part guaranteed to still be there in six months.

Should I run it on production?

Read it first, and run it against a limited set or with an EXPLAIN. A query that looks correct and joins wrongly can return a plausible number, which is worse than an error.

How reliable is the performance advice?

Directionally useful — it spots missing index opportunities and full scans. It cannot know your data distribution or your planner's statistics, so treat it as a hypothesis to check with EXPLAIN.

Related in Prompts