Plain-English → SQL Query Builder
Describe what you want in English, get correct SQL for your actual schema.
Converts plain-English questions into SQL against your real schema. The prompt forces the model to state its assumptions about joins and filters, flag ambiguities in your question, and explain the query back to you in one sentence so you can verify it does what you meant.
The prompt
Variables to fill in: {{dialect}}{{schema}}{{question}}
You are a careful analytics engineer. Write a SQL query for the question below.
Rules:
- Use ONLY tables and columns from the schema I provide. If something needed is missing, say so instead of inventing columns.
- Before the query, state your assumptions in one or two bullets (join logic, how you're interpreting ambiguous terms like "active" or "recent").
- After the query, explain in ONE sentence what it returns, so I can check it matches my intent.
- Prefer CTEs over nested subqueries. Add a comment on any non-obvious line.
- Dialect: {{dialect}}
Schema:
{{schema}}
Question: {{question}}How to use
- 1Paste the relevant CREATE TABLE statements or a column list into {{schema}} — the query is only as correct as the schema you provide.
- 2Set the dialect (Postgres, BigQuery, Snowflake, MySQL) — date functions differ enough to break queries silently.
- 3Read the assumptions bullet before running the query. Wrong join assumptions are the top error source.
- 4Paste back any error message verbatim; it self-corrects well.
Examples
Retention question
Input
Dialect: Postgres. Schema: users(id, created_at), events(user_id, name, created_at). Question: what's our week-2 retention for users who signed up in May?
Output
Assumptions: 'week-2 retention' = any event 8–14 days after signup... ```sql WITH may_signups AS (...) SELECT ... ``` Returns: the % of May signups who logged at least one event in days 8–14 after signing up.
Pro tips
- Keep a saved snippet of your core schema so you can paste it in seconds.
Frequently asked questions
Is it safe to run the generated SQL directly on production?+
Treat it like SQL from a new team member: read the assumptions, sanity-check row counts on a small date range first, and never run generated DML/DDL (UPDATE, DELETE, DROP) without review. This prompt only generates SELECTs by design.
What if my schema is huge?+
Only paste the tables plausibly involved. If you're not sure which, first ask the model 'which of these tables would you need to answer X?' with just table names, then provide those schemas.