AI Prompts for SQL: How to Get Queries You Can Actually Trust

AI prompts for SQL will hand you a query in ten seconds that returns a plausible wrong number. The sequence below - schema first, a reviewed query, a disposable run, then a saved script - keeps that number out of your report.

Generated SQL fails in the worst possible way: it runs, it returns a number, and the number is wrong. No syntax error, no red text - just a sales table that looks reasonable and that somebody is about to paste into a presentation. The cause is rarely bad SQL from the model. It is that we asked for a query without handing over the schema, and then ran it against the database that matters.

Why AI-Written SQL Fails Quietly

One line before anything else: no prompt replaces the person who answers for the number. The model writes the first draft; a human reads it and corrects it, and no generated figure is published or acted on without that review.

The Benchmark Is Not Your Database

On Spider, the academic benchmark built from small, clean databases, the best systems clear 90% execution accuracy - around 91%. On the BIRD benchmark, built from real and messy databases, the best single model lands near 80%. Both numbers describe the benchmark, not your schema, and enterprise write-ups report a large drop once the same models meet production data. "The model knows SQL" says nothing about your database.

The Three Ways a Query Is Wrong but Runs

Three failure modes, not equally dangerous. The first references a table or column that does not exist: it fails loudly, which makes it the friendly one. The second is wrong logic - a JOIN too many, a filter too few - and the result is plausible and false; nothing announces it. The third is a destructive statement with a badly built WHERE, where the damage does not come back. The second is the real danger, because there is no error to notice.

What "Trust" Means Here

Trust here is not trust in the model. It is trust in a procedure: the exact schema in view, a query read by a person, execution in an environment you can throw away, and one number cross-checked against a second source.

Three AI Prompts for SQL, in the Order They Get Trusted

First you stop the model from guessing your schema, then you review what it wrote, then you run it where a mistake is cheap.

Step 1 - Hand Over the Schema, Not Just the Question

DDL Beats Table Names

The most common symptom of generated SQL is a reference to a table or column that does not exist. The model completes by analogy because it was handed a question and no schema. The fix is to give it the exact DDL instead of letting it guess: paste the CREATE TABLE statements for the tables that matter, keys and types included, not a full catalog. The SQL Query & Schema Builder prompt carries that rule built in - never assume a column exists - and asks you for the schema when you do not supply it.

What the Schema Prompt Returns

SQL Query & Schema Builder (coding, $2.99) turns a plain-language need into six blocks: SCHEMA, with keys and useful indexes; THE QUERY, ready for the dialect you name; EXPLANATION, clause by clause; PERFORMANCE, the indexes that speed it up plus an EXPLAIN-style note on the hot path; EDGE CASES, covering NULLs, duplicates, time zones and empty tables; and ALTERNATIVES, a window-function version and a JOIN version.

Say the Dialect Out Loud and Keep the Rows Fake

Every engine has its own quoting, function names and date syntax, so the classic failure is a date function that exists in one engine and not in another. Declare the dialect in the prompt and verify that function before trusting the query. Hand over the schema, never the rows: on consumer accounts chat content may be used to improve the model unless it is turned off, while API and enterprise tiers do not train on customer data by default. Check your own plan - no row belonging to a real client belongs in a chat window.

Step 2 - Review the Query Like a Reviewer, Not a User

Fan-Out: The Wrong Number With the Right Shape

When the JOIN key is not unique on one side, every row multiplies and SUM, COUNT and AVG come out inflated with no error anywhere. Aggregate at the finest grain before joining, and use COUNT(DISTINCT ...) when you count entities rather than rows. The check costs one query: count rows before and after the join on a sample. The same pattern appears in pandas, where a merge on a non-unique key creates phantom rows that inflate a report.

The NOT IN Trap and Other NULL Landmines

If the subquery inside a NOT IN returns even one NULL, every comparison evaluates to UNKNOWN, the WHERE accepts only TRUE, and the query returns zero rows with no error and no warning. Rewrite it as NOT EXISTS, or filter the NULLs first. The same pass covers time zones, since a timestamp stored without one can move a month of sales, and empty tables, which change results silently.

Cross-Check One Number You Already Know

Verifying a report takes just enough SQL: reading SELECT, JOIN and CTE well enough to tell whether the query does what it claims. A validation suite that repeats across teams has five stages - it compiles, it references only permitted datasets, it uses approved join paths, it returns the expected columns, and only then does logic review start. The practical version: pick one total you already know from another source and compare it. If it does not match, the query is the thing that is wrong.

Step 3 - Run It Somewhere Disposable

A Read-Only Replica Is the Cheapest Guardrail

Ad-hoc analysis and generated queries do not belong on the database serving the business. Point them at a read-only replica: managed engines offer a read-scale endpoint, and databases on availability groups expose a readable secondary, the case Microsoft documents as read scale-out. With the account in read-only mode as well, a generated DROP becomes an error instead of an incident.

Transaction, Measure, Roll Back

For an UPDATE or a DELETE, the pattern that repeats is to wrap the statement in a transaction, measure the state before and after, and always roll back - showing the real diff to a person before anything is approved.

LIMIT, EXPLAIN and the Pre-Flight

Run the query with LIMIT 100 first to see what comes back, ask for the execution plan on large tables, and for any write statement run the matching SELECT with the same WHERE clause to count the rows it would touch.

Step 4 - Turn the Approved Query Into Something Reusable

A Script Beats a Chat Window

A query approved inside a chat window is lost by Thursday; the SELECT you reviewed should become a file you can rerun. Python Data Analysis Script (coding, $2.99) asks for a complete, runnable pandas script: robust reading with missing values handled and types detected; the analysis in commented steps; output as a printed summary, a PNG chart and an exported CSV; a small CSV fixture; and handling for edge cases such as an empty dataframe. Its rules are modern pandas, no hardcoded paths because it reads sys.argv, and a __main__ guard.

Keep the Fixture Small and Fake

The same prompt asks for a fixture of five to ten rows on purpose. That file is what gets shared when you ask for help and what goes into the repository: synthetic, with no names, emails or customer identifiers.

The Pre-Flight Checklist Before a Query Touches Real Data

Eight points, short enough to read every time:

• The schema you see matches the real one.
• The dialect is declared and its date function verified.
• Every write statement has a WHERE clause.
• Rows were counted before and after the JOIN.
• The NULLs in the comparison columns are resolved.
• The twin SELECT ran before every UPDATE or DELETE.
• Execution was read-only, or in a transaction that was rolled back.
• The final number was cross-checked against a known source.

Start with the SQL Query & Schema Builder to get a query against the real schema, and use the Python Data Analysis Script to turn the version you approved into something repeatable. The value is not in the query that was generated - it is in the one that was reviewed, corrected and saved. The model writes the first draft; the person who answers for the number reads it and signs it.