SQL Query Prompt Generator: Write, Fix and Optimise Queries

Why SQL prompts need the schema

Ask an AI for "a query that finds each customer's first order" and it will invent table and column names, then guess at your data types. The query looks right and fails on your database. The single most useful thing you can do is paste your actual tables and columns, ideally the CREATE TABLE statements, plus a note on keys and what status values exist. The second most useful is one expected result row, which lets the model check its own logic.

The builder also fixes the dialect. Date functions, string handling, LIMIT versus TOP, and window function support differ between PostgreSQL, MySQL, SQL Server, BigQuery and SQLite. The prompt names the dialect and forbids functions it does not have. For slow queries it asks for an explanation of why the query is slow, which indexes would help, and a rewrite, instead of a rewrite alone. For wrong results it asks the model to state what the current query actually computes before fixing it, which catches misunderstandings about the question.

Edge cases are where real queries break: nulls in join columns, duplicate rows after a join, time zones in timestamps, refunded orders counted as revenue. The optional edge-case list makes the model name them so you can decide, rather than silently picking one behaviour.

Worked example

Say you need a cohort-style query in PostgreSQL and want it right the first time. These are the inputs:

What do you need?

write a new query

Database

PostgreSQL

Question or goal in plain words

For each customer, the date of their first completed order and the total they spent in the 90 days after it

Tables and columns (paste CREATE TABLE or describe)

customers(id, name, country, created_at); orders(id, customer_id, status, total_cents, ordered_at); status is one of: pending, completed, refunded

Sample rows or expected result

expected: customer 42, first_order 2026-03-01, spend_90d 184.50 (euros, not cents)

Data size

medium (millions of rows)

Query style

CTEs (WITH) for readability

Explain the query step by step

Yes

List edge cases (nulls, duplicates, time zones)

Yes

Add a small test with sample data

No

The builder turns these inputs into the following prompt. Load it into the form above with the First-order cohort example chip and change anything you like.

You are a senior database engineer who writes correct, readable PostgreSQL queries and explains them precisely.

## Task
Write a PostgreSQL query for this question:
For each customer, the date of their first completed order and the total they spent in the 90 days after it

## Schema
customers(id, name, country, created_at)
orders(id, customer_id, status, total_cents, ordered_at)
status is one of: pending, completed, refunded

## Sample rows / expected result
expected: customer 42, first_order 2026-03-01, spend_90d 184.50 (euros, not cents)

## Requirements
- Use only syntax and functions available in PostgreSQL.
- Use my exact table and column names. If something needed is missing from the schema, ask instead of guessing.
- Data size: medium (millions of rows).
- Style: CTEs (WITH) for readability.
- List edge cases and how the query handles them: NULLs in join or filter columns, duplicate rows after joins, time zones and date boundaries, and rows with unexpected status values.
- Check the query against the sample or expected result and say whether it matches.

## Output format
The query in a single ```sql code block, then a step-by-step explanation of each part. State any assumptions clearly.

This page shows only the prompt. The answer depends on the AI tool you paste it into, so always review the result before you use it.

Tips to improve your results

• Paste real column names and types. Even a rough "orders(id, customer_id, total_cents, ordered_at)" beats a description.
• State what the status or type values mean; the model cannot know that "refunded" should be excluded.
• Give one expected result row for a known case and ask the model to check its query against it.
• For performance questions, include row counts and existing indexes.
• Run generated queries on a copy or with a LIMIT first, and never paste production credentials or customer data into a prompt.