People use ChatGPT for SQL. Here's what it can't see.

What ChatGPT does well here

Ask ChatGPT to write a query for "the top 5 customers by total order value in the last quarter" and it will produce something syntactically correct, with a reasonable JOIN and GROUP BY structure, in whatever dialect you specify. For learning SQL syntax, working through a generic problem, or writing a query against a schema you're willing to describe by hand, it's a genuinely useful tool, and there's no reason to pretend otherwise.

Where the gap actually shows up

The problem isn't SQL knowledge. It's that ChatGPT, used on its own, has no connection to your database. Ask it to write a query against "the orders table" and it invents plausible column names, order_date, customer_id, total_amount, that may or may not match what you actually have. You find out they don't match when you run it and get a column-not-found error, which is the same debugging step you were trying to skip by asking an AI in the first place.

A concrete comparison

Ask ChatGPT: "write a query for daily active users over the last 30 days." A typical response:

-- ChatGPT's guess at your schema
SELECT DATE(event_timestamp) AS day, COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_timestamp >= NOW() - INTERVAL '30 days'
GROUP BY day
ORDER BY day;

Reasonable SQL. But if your actual table is analytics_prod.activity_log with a column called occurred_at instead of event_timestamp, this fails the moment you run it. Ask the same question in QueryFlow's Ask panel against your real BigQuery connection, and it comes back already using your names:

SELECT DATE(occurred_at) AS day, COUNT(DISTINCT user_id) AS dau
FROM `analytics_prod.activity_log`
WHERE occurred_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY day
ORDER BY day;

Same question, correct table and column names on the first try, because the panel read them from the connection instead of guessing.

The manual workaround, and its cost

You can close this gap yourself by pasting a CREATE TABLE statement or a column list into the ChatGPT conversation before asking your question. It works, for that one conversation, on that one table. The moment the schema changes, or you're asking about a different table you didn't paste, you're back to guessing, or pasting again. It's a workable habit for occasional use and a genuine chore if you're doing it several times a day.

Running the query is a separate step either way

ChatGPT also can't run anything, you copy the SQL out to wherever your database client lives and run it there, which is where the schema mismatch actually surfaces. QueryFlow's Ask panel closes that loop: once it writes a query, Run, Insert into editor, and Watch this sit right under it, no copy-paste round trip.

Where ChatGPT is still the better choice

For a question that has nothing to do with a specific database, general SQL syntax, how a window function works, whether to use a CTE or a subquery, ChatGPT (or any general-purpose model) is just as good and doesn't require a database connection at all. This page isn't arguing ChatGPT is bad at SQL. It's pointing at the one thing it structurally can't do without your help: know what your database actually looks like.

Debugging an error is the same story

The same gap shows up when a query fails and you paste the error into ChatGPT for help. Without the actual table definitions, it can explain what a "column does not exist" error generally means, but it can't tell you which of your columns you meant instead, because it's never seen the list. QueryFlow's Ask panel can attach Last error directly to a question, and because it already has schema access, it can usually point at the specific column name that's close to what you typed and suggest the fix directly, rather than explaining the category of error in the abstract.

A quick gut check before trusting either one

Whichever tool wrote the SQL, the same habit applies before running it against anything that isn't a plain SELECT: read the WHERE clause, confirm the table name is the one you meant, and run it against a LIMIT first if it's going to touch a lot of rows. An AI assistant with full schema access is right more often than one guessing blind, but "more often" isn't "always," and the five seconds it takes to glance at generated SQL before running it costs a lot less than cleaning up after a wrong one.