Testing a Free AI SQL Assistant Against a Real Schema: A Practical Workflow

Generating SQL with AI is the easy part. Knowing whether the generated query is correct for your schema, your dialect and your business rules is where the time actually goes.

This post walks through a repeatable workflow for evaluating AI-generated SQL, with the failure modes worth checking for. It closes with a look at the free Express edition of dbForge AI Assistant introduced in dbForge 2026.2, as one example of an assistant that works inside the IDE.

Total revenue per product category for last quarter, excluding cancelled orders.

Before any tool can answer that correctly, someone needs to resolve:

If the assistant only sees the prompt, it fills those gaps with assumptions. So step one is removing as many assumptions as you can.

Drafts produced from this kind of input are much easier to review. Tools that read schema metadata directly save you from retyping the structure every time.

The most common silent bug in generated SQL is row multiplication from a one-to-many join. Here is an illustrative example (written for this post, not output from any tool):

-- Looks reasonable, but can inflate totals SELECT c. customer_id, SUM ( o. order_total ) AS total_spent FROM customers c JOIN orders o ON o. customer_id = c. customer_id JOIN payments p ON p. order_id = o. order_id WHERE p. status = 'paid' GROUP BY c. customer_id; Enter fullscreen mode Exit fullscreen mode If an order can have more than one paid payment row, each order_total is counted once per payment. The query runs fine and returns wrong numbers. A safer version checks the condition without changing the grain:

SELECT c. customer_id, SUM ( o. order_total ) AS total_spent FROM customers c JOIN orders o ON o. customer_id = c. customer_id WHERE EXISTS ( SELECT 1 FROM payments p WHERE p. order_id = o. order_id AND p. status = 'paid' ) GROUP BY c. customer_id; Enter fullscreen mode Exit fullscreen mode Whether this matches your definition of "paid" is a business decision, which is exactly why the reviewer, not the model, makes the call. Quick checks worth running on any generated aggregate:

When something looks off, a targeted follow-up works better than "fix this":

Here is the query, the error message, and the result I expected. Dialect: PostgreSQL 16. Explain what each join and filter does, then propose the smallest change that produces the expected result, and explain it. Enter fullscreen mode Exit fullscreen mode Minimal diffs are easier to review than full rewrites, and the explanation tells you whether the model understood the problem or just reshuffled the query.

Suggested rewrites and indexes are a starting point for investigation. Validate them like a colleague's suggestion:

Generated UPDATE, DELETE and DDL statements go to a test database first. Run them inside a transaction you can roll back, and review them like any pull request.

Every step above involves moving between a prompt, a database and an editor. An assistant inside the database tool removes some of that switching.

dbForge 2026.2 introduced a free Express edition of dbForge AI Assistant, which runs inside dbForge products rather than as a standalone app. The parts relevant to this workflow:

The Express edition has a limited token allowance and keeps chats for 14 days. Paid plans raise the allowance and remove the history limit.

A sensible evaluation: run Steps 1 through 5 against a query you have already debugged, and see whether in-tool context shortens the loop for your schema.

AI makes first drafts cheap. Correctness still comes from context, grain checks, minimal diffs, measured performance and careful handling of writes. Build those habits once and they carry over to whichever assistant you end up using.

Based on The AI Journal, "Free AI SQL Assistant Is Now Available in dbForge 2026.2".