SQL Prompts for Analysts: Schema-Safe Query Asks

TL;DR: SQL prompts work when you hand the model your schema, name your SQL dialect, and forbid it from inventing tables or columns. You paste the DDL or a column list, state the business question in one sentence, ask the model to list its assumptions before the query, and require short comments that explain each join and filter. This page gives analysts a schema-safe template, five paste-ready kits (KPIs, cohorts, debugging, performance, dialect moves), a review checklist, and FAQ answers for ChatGPT, Claude, and Gemini work as of September 2026. PromptMake at https://promptmake.net/text can turn a rough data question into a labeled prompt before you paste it into your chat model.

What SQL prompts need that general coding prompts skip

A chat model writes fluent SQL on the first try. The danger sits in the names. Ask “show me monthly revenue by region” with no schema and the model will guess a table called orders, a column called revenue, and a join to regions that your warehouse never had. The query looks right, runs nowhere, or worse, runs against a similar table and returns wrong numbers that land in a slide deck. Analysts need prompts that pin the model to real objects, the real dialect, and the real metric definition. General coding prompts focus on diffs, tests, and refactors. SQL prompts focus on grain, joins, NULLs, and time, because those four choices decide whether a number is correct. The two H3s below cover the inputs that fix most bad queries before you run them.

Schema is the ground truth

Paste the CREATE TABLE statements or a clean column list for every table the query may touch. Include data types, primary keys, and foreign keys. Add one line per table that states its grain, for example “one row per order line” or “one row per user per day.” Grain tells the model when a join will fan out and double-count revenue.

Add two or three masked sample rows when a column holds codes the model cannot decode from the name, such as status = 3 or channel_id = 'PPC_B'. Remove emails, names, and card data first. Then write the rule in plain words: “Use only the tables and columns listed in SCHEMA. If you need a field that is missing, stop and ask.”

Dialect changes the answer

Date math, string functions, and window syntax differ across engines. PostgreSQL uses DATE_TRUNC('month', created_at). BigQuery GoogleSQL uses DATE_TRUNC(created_at, MONTH). Snowflake, SQL Server, MySQL, and DuckDB each bring their own quirks for QUALIFY, TOP, interval math, and case sensitivity.

Name the engine and version in the first line of the prompt: “Dialect: PostgreSQL 16” or “Dialect: BigQuery GoogleSQL.” State the time zone your timestamps use and the one you report in. Many “wrong total” bugs trace back to UTC data grouped as if it were local time.

The schema-safe SQL prompt template

The template below keeps the model inside your warehouse. It has seven labeled fields, and each one blocks a common failure. DIALECT stops syntax drift. SCHEMA and GRAIN stop invented objects and fan-out joins. METRIC pins the business definition so “active user” means what finance means. ASSUMPTIONS forces the model to show its guesses before it writes code, which gives you a cheap review step. RULES forbids writes and invented names. OUTPUT fixes the shape so you can scan the answer in under a minute. Copy it into a doc, fill the slots once per project, and reuse the SCHEMA block across questions so you stop retyping table names.

The template you can paste

• DIALECT: [engine and version, for example PostgreSQL 16 or BigQuery GoogleSQL]. Timestamps stored in [UTC]; report in [America/New_York].
• SCHEMA: [paste CREATE TABLE statements or column lists with types and keys].
• GRAIN: [one line per table, for example orders = one row per order; order_items = one row per line item].
• METRIC: [exact business definition, for example net revenue = sum of item_price * quantity minus refunds, excluding test accounts where is_test = true].
• QUESTION: [one sentence, for example monthly net revenue by region for January to June 2026].
• ASSUMPTIONS: Before the query, list every assumption you make about joins, NULLs, date boundaries, and filters. If an assumption needs a column that is not in SCHEMA, stop and ask me.
• RULES: Use only tables and columns in SCHEMA. SELECT statements only. No INSERT, UPDATE, DELETE, DROP, or CREATE. Add a comment above each join and each WHERE filter that explains why it exists.
• OUTPUT: (1) assumptions as a numbered list, (2) one SQL query in a code block, (3) a two-line note on how the result could be wrong.

A filled example

DIALECT: PostgreSQL 16, timestamps in UTC, report in UTC. SCHEMA: orders(order_id bigint pk, user_id bigint, created_at timestamptz, status text), order_items(item_id bigint pk, order_id bigint fk, price_cents int, qty int), users(user_id bigint pk, region text, is_test boolean). GRAIN: orders one row per order; order_items one row per line; users one row per user. METRIC: net revenue = sum of price_cents * qty for orders with status = 'paid', excluding is_test users. QUESTION: monthly net revenue by region for 2026-01-01 to 2026-06-30.

A good answer lists assumptions such as “status = 'paid' excludes refunds” and “users with NULL region appear as 'unknown'.” It joins order_items to orders on order_id, joins users on user_id, groups by DATE_TRUNC('month', created_at) and region, and comments each step. If the model instead invents a refunds table, the RULES line gives you grounds to reject the answer and re-ask.

Five SQL prompt kits for common analyst asks

Most analyst requests fall into a handful of job types, and each type fails in its own way. KPI pulls fail on metric definitions. Cohort queries fail on date boundaries and survivor bias. Debugging asks fail when the model rewrites the whole query instead of finding the one broken join. Performance asks fail when the model suggests indexes you cannot create in a managed warehouse. Dialect moves fail on functions that look alike but treat NULLs in their own way. Each kit below adds two or three lines to the base template from the previous section. Keep DIALECT, SCHEMA, GRAIN, and RULES in place, then swap the QUESTION and OUTPUT lines for the kit you need.

Kit 1: KPI and aggregation pulls

Add: “Return one row per [month] per [dimension]. Show the count of source rows next to each total so I can spot fan-out. If two tables share a key at different grains, aggregate the finer table in a CTE before the join.” The row-count column exposes double-counting at a glance.

Kit 2: Cohort and retention queries

Add: “Define cohort as the month of each user's first paid order. Retention month N = users with at least one paid order in cohort month + N. Use half-open date ranges (>= start and < end). Output a long table: cohort_month, month_number, users_retained, cohort_size.” Half-open ranges stop the classic last-day-of-month gap.

Kit 3: Debug a query that returns wrong numbers

Paste the failing query, the number you expected, the number you got, and how you know the expected one. Add: “Do not rewrite the query. Find the single most likely cause, quote the exact lines, and propose the smallest change. Then give me one diagnostic query I can run to confirm the cause.” The diagnostic query keeps you in charge of the verdict.

Kit 4: Rewrite for performance

Paste the query and the plan output from EXPLAIN (or EXPLAIN ANALYZE on a safe copy). State what you can change: “I can add CTEs and rewrite filters. I cannot create indexes or change table clustering.” Add: “Explain each change in a SQL comment and state which plan node it targets.” This keeps the model's advice inside your permissions.

Kit 5: Move a query between dialects

Add: “Translate from [Snowflake] to [BigQuery GoogleSQL]. List every function you replaced and any behavior difference with NULLs, time zones, or integer division. Keep column aliases identical so downstream dashboards still work.” The replacement list doubles as your test plan.

Step-by-step: from business question to reviewed query

The workflow below takes about ten minutes the first time and three once your SCHEMA block lives in a doc. It treats the model as a fast drafter and you as the reviewer who owns the number.

1. Rewrite the stakeholder ask as one QUESTION sentence with a date range and a dimension.
2. Copy the relevant DDL from your warehouse catalog or dbt models. Trim tables the question does not need.
3. Write GRAIN lines and the METRIC definition. Ask the metric owner if you are unsure.
4. Paste the template, send it, and read the ASSUMPTIONS list before you read any SQL.
5. Correct wrong assumptions in one reply. Ask for a revised query only after the assumptions match reality.
6. Run the query with a LIMIT or on a narrow date range first. Compare one total against a trusted dashboard or a hand count.
7. Save the final prompt and query in your team notes with the date and the warehouse version.

Step 4 does most of the work. When the model writes “I assume created_at is in local time,” you catch the time zone bug before it reaches a chart.

Common mistakes with SQL prompts

Asking without a schema tops the list. The model fills gaps with plausible names, and plausible names are the ones you will not catch in a quick skim.

Pasting the whole warehouse catalog comes next. Two hundred tables bury the five that matter and push the model toward the wrong customers table. Paste only what the question needs.

Skipping the metric definition lets the model pick its own. “Revenue” can mean gross, net of refunds, net of tax, or recognized revenue. Write the one your finance team uses.

Letting the model run writes is a risk even in a sandbox. Keep the SELECT-only rule in every prompt, and connect any agent tool to a read-only role.

Trusting the first number without a cross-check skips the analyst's core job. Compare one cell against a known source before you share the result.

Treating SQL prompts like general coding prompts misses the grain and NULL checks. For app code, debugging stack traces, and refactors, read https://promptmake.net/blog/chatgpt-prompts-for-coding or https://promptmake.net/blog/claude-prompts-for-coding. This page stays on analyst queries against a schema you paste.

Model and warehouse notes for 2026

As of September 2026, GPT-5.6 Sol, Claude Opus 5, and Gemini 3.1 Pro handle multi-CTE cohort logic and dialect translation well when the schema is present. Faster tiers such as GPT-5.5 Instant, Claude Sonnet 5, and Gemini 3.5 Flash suit quick aggregations and syntax lookups. For reasoning-class models, state the goal, constraints, and output shape; you do not need “think step by step.”

Warehouse AI assistants, such as the text-to-SQL features inside BigQuery, Snowflake, and Databricks, read your catalog for you. The same prompt habits still help: name the metric, state the grain, and ask for assumptions. A connected assistant can still pick the wrong table when two tables share a name across schemas.

Keep sensitive data out of chat. Paste structure and masked samples, never raw customer rows. Check your company's approved-tool list before you paste any production DDL into a consumer chat app.

Draft SQL prompts with PromptMake /text

If your starting point is a vague Slack message like “can you pull churn for enterprise last quarter,” open https://promptmake.net/text, paste the message plus your table names, and pick the model you plan to use. The tool returns a labeled prompt with role, task, constraints, and format slots that you can map onto the DIALECT, SCHEMA, and METRIC fields above.

PromptMake writes prompt text only. It does not connect to your warehouse, read your schema, or run queries. Guests get about three runs per day on /text and free registered accounts about five, as of September 2026. Paste the output into ChatGPT, Claude, or Gemini, then add your real DDL before you send.

FAQ

What are SQL prompts?

SQL prompts are instructions you give a chat model to write, fix, explain, or translate SQL queries. Strong SQL prompts include the schema, the dialect, the metric definition, and rules that forbid invented columns. They also ask the model to state its assumptions before the query. That structure turns the model into a fast drafter you can review.

How do I stop ChatGPT from inventing column names?

Paste the exact table definitions and add a rule: “Use only tables and columns in SCHEMA; if a field is missing, stop and ask.” Ask for an assumptions list before the query so guesses show up in plain text. Reject any answer that names an object outside your paste. Re-ask with the missing table added if the model had a valid need for it.

Should I paste my full database schema into the prompt?

Paste only the tables the question needs, plus their keys and grain lines. A full catalog adds noise and raises the odds that the model joins the wrong table. For large warehouses, keep a short schema block per subject area, such as orders or marketing. Mask or drop any column that holds personal data.

Which AI model writes the best SQL in 2026?

As of September 2026, GPT-5.6 Sol, Claude Opus 5, and Gemini 3.1 Pro handle complex joins, window functions, and dialect moves well when you give them the schema. Faster tiers work for simple aggregates and syntax lookups. The prompt matters more than the model for correctness, because no model can see a schema you did not paste. Test two models on one known query before you pick a default.

How do I ask for a query in a specific SQL dialect?

Put the engine and version on the first line, such as “Dialect: BigQuery GoogleSQL” or “Dialect: PostgreSQL 16.” Add your storage and reporting time zones. When you translate a query, ask the model to list each replaced function and any NULL or integer-division difference. That list becomes your test checklist.

Can I use SQL prompts to explain an existing query?

Yes. Paste the query and the schema, then ask for a line-by-line explanation, the grain of the result, and any join that could duplicate rows. Ask the model to flag filters that drop NULLs without saying so. This works well for onboarding onto inherited dashboards and dbt models.

Is there a free tool to build SQL prompts?

PromptMake /text at https://promptmake.net/text turns a rough data question into a structured prompt for free, with about three guest runs per day and about five for registered accounts. It writes prompt text only and never connects to your database. You still paste your schema and run the query yourself. Save your best filled template so the next question takes minutes.