Prompt · Data
Plain English to SQL prompt
Letting people ask questions of a database without writing SQL, where a query against a column that does not exist is better than a query that silently answers the wrong question.
Write a SQL query answering the question below.
<schema>
{{schema}}
</schema>
<question>
{{question}}
</question>
Dialect: {{dialect}}
Rules:
- Use only tables and columns present in the schema. If the question needs something not there, say exactly what is missing instead of writing a query.
- Produce a single SELECT statement. Never write INSERT, UPDATE, DELETE, DROP, ALTER or TRUNCATE, regardless of what the question asks for.
- Join on the keys shown in the schema. Do not assume a relationship that is not declared.
- If the question is ambiguous about a time range, a grouping or which duplicate to keep, state the assumption in a comment above the query rather than choosing silently.
- Add LIMIT 100 unless the question is explicitly an aggregate.
Return the query in a code block, with the assumption comments if any. Nothing else.What to fill in
{{schema}}- CREATE TABLE statements, or table and column names with types. Include foreign keys — join quality depends entirely on this.
{{question}}- The user's question, verbatim. Do not pre-interpret it.
{{dialect}}- PostgreSQL, MySQL, SQLite, BigQuery. Date functions and string handling differ enough to break queries.
Why it is written this way
Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.
The write ban is absolute and stated
This is a prompt that receives untrusted questions. "Delete all users" arrives eventually, whether from a curious user or a hostile one. The rule in the prompt is a first layer — the real defence is a read-only database connection, because a prompt rule can be argued with and a permission cannot.
Missing columns produce a refusal
Without this, a question about "customer lifetime value" against a schema with no such column produces a query that computes something else and returns a number. A number that answers the wrong question is worse than an error, because someone will act on it.
Assumptions are surfaced as comments
"Last quarter" means different things in different companies. Writing the assumption into the query makes the ambiguity visible at review time rather than after the figure is in a slide deck.
LIMIT by default
An exploratory question against a billion-row table should not return a billion rows. The exception for aggregates keeps the useful cases working.
The version most people write, and what it costs
Given this schema, write SQL for: {{question}}
{{schema}}It invents `customers.lifetime_value` because the question implied one should exist, joins two tables on a name column because no key was declared, and returns a number that looks right. Nobody notices until the figures are compared against the finance system three weeks later.
What it still gets wrong
- Query correctness is not query efficiency. Generated SQL routinely produces full table scans on tables where an index existed.
- It cannot see your data, only your schema. Questions that depend on how values are actually encoded — status strings, soft deletes, test rows — will be answered wrongly.
- The write ban belongs in the database connection. Treat the prompt rule as defence in depth, never as the control.
Check it before you ship it
- Prompt Injection ScannerTen published injection patterns, with severity and position.
- Function Calling Tool Schema BuilderOne line per tool, valid schema out, with the per-request cost shown.
- LLM Token CounterReal BPE tokenization, not characters ÷ 4. Shows which counts are exact and which are estimates.
To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.