SQL Generator

About the SQL Generator

The gap between knowing what you want from a database and writing the query for it is mostly syntax you use too rarely to remember. Window functions, date arithmetic, and the particular way each product does pagination are the three that send people to a search engine every single time, because the answer differs between products in ways nothing else does.

Ask the question here in plain words, paste your tables, and the query comes back in the dialect you name. Six are covered, and the differences between them are not cosmetic: date handling, string functions, limits and pagination diverge sharply, and a query copied from a PostgreSQL answer into SQL Server usually fails on the first of those.

Pasting the schema is the single thing that most changes the quality of the result. Without it the query has to invent your column names, and it will invent reasonable ones that are not yours, leaving you to rename half of them. Table and column names in any form work — a create statement, or just orders(id, customer_id, total, created_at) on a line.

It writes SELECT statements only. Ask for an update or a delete and it says so instead, which is a deliberate limit rather than an omission: a generated statement that modifies data is a bad idea in a text box with no undo, and anyone who genuinely needs one is better served writing it themselves with the table in front of them.

Where the question implies keeping rows that have no match, it uses an outer join and says what happens to them, which is the join mistake that silently drops data and produces a number nobody questions.

The explanation covers what the query does and flags anything that will be slow on a large table — a function wrapped around an indexed column, a correlated subquery in the select list, a join with no usable condition. It cannot know your indexes or your row counts, so read it as a prompt to check rather than a verdict.

How to use it

1. 1Write the question in plain English, including any filters or date ranges you need.
2. 2Paste your tables and columns in the schema box. This matters more than any other setting.
3. 3Choose the dialect you actually run against — the differences are real.
4. 4Read the query before running it, and run it on a copy or with a limit first.
5. 5Check the performance notes against your own indexes, which the page cannot see.

Questions

Why will it not write an update or a delete?

Because there is no undo behind a text box, and a generated statement that modifies data can be subtly wrong in ways a read query cannot — a missing where clause updates every row and returns no error. Read queries can be checked by looking at what comes back. Write queries are checked by the damage.

Do I have to give it my schema?

No, but the result is much better with it. Without a schema it uses plainly-named placeholders and tells you which names it assumed, so you can substitute your own. With one it uses your actual columns and will tell you if the question needs something your tables do not have.

Is it safe to paste my table structure?

That is your call to make, and it is worth making deliberately. Table and column names go to the AI provider like everything else in this category. They are not usually secret, but they do describe your systems. Paste the tables the question needs and leave the rest out.

Will the query be efficient?

It will be reasonable and it may not be optimal, because efficiency depends on indexes, row counts and statistics that this page cannot see. The notes flag the patterns that are commonly slow. Run it against an execution plan before putting it anywhere it will run often.