Generate SQL from plain English

I know what data I need, I just do not want to hand-write every join. This closes the gap.

The workflow

1. Describe your tables and the question
2. Ask ChatGPT for the SQL plus a one line explanation
3. Run it on a read replica first
4. Save the good ones as snippets

Result: Correct SQL for most day-to-day questions, with the reasoning shown.

The prompt

Here is my schema: [PASTE]. Write a SQL query that answers: [QUESTION]. Explain the joins in one line and flag any assumption.

A note on what follows. The workflow, the prompt and the result above come from the member. The notes below (why the prompt works, what to watch for, how to adapt it) were written with AI help.

Why this prompt works

"Flag any assumption" is the line that makes this safe to use. The query itself is usually fine. What used to get me was the silent decision: whether a cancelled subscription counts on the day it cancelled, whether a null end date means active or means broken data. It picks one, writes correct SQL for that choice, and without the flag you never learn a choice was made. Now it tells me, and half the time I disagree, which is the point. Pasting the schema rather than describing it also matters more than I expected. Describe it and you get plausible column names that do not exist. Paste the DDL and it uses what is there.

What to watch for

• Dialect drift. It writes something Postgres-shaped when you are on MySQL, especially around date functions.
• Join fan-out. A one-to-many join quietly multiplies your totals and the query still runs happily.
• It optimises for readability, not for your indexes. Fine on a small table, painful on a large one.
• Ambiguous time windows. "Last 6 months" can mean six calendar months or 180 days and the difference shows up in the numbers.

How to adapt it

• Pin the dialect: Postgres 15. Use date_trunc, not DATE_FORMAT.
• For anything that will run often, add Show the query plan concerns and which indexes this assumes.
• When the totals look wrong, ask Rewrite this to avoid join fan-out and explain where the duplication came from.

What good output looks like

The assumptions list should contain something I want to argue with. If it says "no assumptions", either the question was trivial or it made a call quietly, and it is usually the second. I run everything on a replica first and sanity check one number against a known figure. A query I cannot explain back to myself in a sentence does not go into a dashboard, however right it looks.