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.

The problem: prompts are underspecified

Take a typical request:

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

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

• Which table defines revenue: order lines, invoices or payments?
• Are refunds subtracted? Are discounts applied per line or per order?
• What are the quarter boundaries, and in which time zone?
• Which statuses count as cancelled?
• Which engine and version? Date functions and row limiting differ across SQL Server, MySQL and PostgreSQL.

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

Step 1: Give the model real context

Useful context includes:

• Table and column names, plus keys and relationships
• The SQL dialect and version
• Business rules, for example "revenue = paid invoice lines minus refunds"
• The expected output shape: columns, grain, ordering
• Team conventions such as naming, formatting or CTE versus subquery preferences

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.

Step 2: Check the grain before the numbers

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;

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;

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:

• Compare COUNT(*) with COUNT(DISTINCT key) at each join stage
• Spot-check a handful of rows against a source you trust
• Look for filters on nullable columns that may drop valid rows

Step 3: Ask for explanations and minimal fixes

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.

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.

Step 4: Treat performance advice as a hypothesis

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

1. Confirm the revised query returns the same rows as the original.
2. Compare execution plans.
3. Compare elapsed time and resource usage under the same conditions.
4. For index suggestions, check whether an existing index already covers the predicate, and weigh the write and storage cost.

Step 5: Fence off writes

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.

Where an in-IDE assistant fits

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:

• Schema context: attach a database and the AI Assistant works with its metadata, such as schema and index information. Several databases can share one chat, and two scripted databases can be compared.
• File context: attach application code, database projects, diagrams, sample SQL or custom instructions, and optionally auto-attach the document you are editing.
• Editor round trip: generated SQL moves into the SQL editor, where you test it.
• Capabilities: generating, explaining, fixing and optimizing SQL, plus questions about SQL and dbForge features.
• Engines: SQL Server, MySQL, MariaDB, Oracle, PostgreSQL and cloud services based on them.
• Model choice: Anthropic and OpenAI models can be selected under Tools > Options > AI Assistant > General.

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.

Wrapping up

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".