DEV Community: David Murray

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

David Murray — Tue, 13 Oct 2026 09:19:19 +0000

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:

Confirm the revised query returns the same rows as the original.
Compare execution plans.
Compare elapsed time and resource usage under the same conditions.
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".

dbForge AI Assistant: A Developer's Tour of What It Actually Does

David Murray — Mon, 21 Sep 2026 17:21:15 +0000

Every database tool ships an AI assistant now, and most of the marketing sounds identical: plain English in, SQL out. That's the easy part. The more useful question for anyone actually deciding
whether to turn one on is what it does once you're past the first demo query, across a real editing session, on a real schema, in whatever database engine you're actually using.dbForge AI Assistant, built into dbForge Studio for SQL Server and the rest of the dbForge product line,
is worth a proper walk-through for exactly that reason. Here's what it covers, feature by feature.

Plain English to working SQL

The core loop is text to SQL. Attach a database, describe what you want in a sentence, and the assistant returns valid SQL mapped to your actual schema, not a generic template. Because the
schema is attached rather than pasted in as context, the same request against two different databases returns two different, correctly scoped queries. This is the baseline capability, and it's also the one most AI SQL tools advertise. What differentiates a database-native assistant from a general chatbot is everything below.

Optimizing and troubleshooting queries

Correct SQL and fast SQL are not the same thing, and this is where database context starts to matter.
Paste in a query and the assistant returns an optimized version along with practical suggestions, flagging inefficient indexes and pointing at concrete ways to improve execution rather than generic
textbook advice.
A recent hands-on demo from IT educator Frank, who runs the YouTube channel Learning and Technology with Frank, shows this in practice with a 2026.1 update that has the assistant read a database's actual index metadata, the B-tree and unique indexes underneath the schema, before it recommends a rewrite. He attached a copy of Microsoft's AdventureWorks sample database, ran a generated query, asked the assistant to optimize it, and got back a rewrite that used indexes already present rather than suggesting new ones blind. It's a useful illustration of what context-aware optimization means in practice: recommendations grounded in indexes that actually exist, not ones that might.

Fixing and explaining SQL

Two related, everyday capabilities: error detection with auto-fix, and clause-by-clause explanation. The first spots issues in a query and returns a corrected version you can run immediately. The second
breaks down what a query does and how it produces its results, in plain language.
Both are aimed less at greenfield work and more at the SQL you inherited: the two-hundred-line stored procedure with no comments, the query a former teammate wrote two years ago that nobody fully
trusts. Paste it in, ask what it does, get a walkthrough instead of an afternoon of manual tracing.

Beyond single queries

The advanced feature set covers the parts of database work that sit around query writing rather than inside it: AI-powered formatting and style enforcement for consistent SQL across a team, generation of
stored procedures and functions from a prompt, AI-assisted unit testing that generates tests for database objects with comments explaining how each one works, transaction and error-handling
recommendations to prevent deadlocks and missed rollbacks, and reusable snippets you can insert from the context menu. None of these are headline features on their own, but together they cover a meaningfully larger share of routine database work than text-to-SQL alone.

AI chat, for when you have a question

Separate from any specific query, the assistant answers general SQL questions and questions about the dbForge product itself, in real time, without leaving the editor. Useful for the kind of question that would otherwise mean a tab switch to a search engine or a forum.

Where it runs, and what it sends

dbForge AI Assistant works across SQL Server, MySQL and MariaDB, Oracle and PostgreSQL, and runs inside compatible dbForge products, including dbForge Studio for SQL Server and the other engine-specific Studios, dbForge Edge, and a range of standalone dbForge tools. The same capability set applies regardless of which supported engine you're attached to.
Worth knowing if you're evaluating it for a team with data governance requirements: the assistant sends database metadata for context, not the actual data in your tables, and only your conversation is stored
on the server. Conversations are not used for model training. It's off by default in any dbForge product and has to be explicitly enabled.

If you're deciding whether to turn on an AI assistant inside your database tool, that's the right frame: does it ground its answers in your actual schema and indexes, across the engines you actually use,
and does it explain itself well enough that you're learning something, not just accepting output. dbForge AI Assistant works across the four major engines from inside the dbForge Studios and the otherdbForge tools most SQL Server, MySQL, Oracle and PostgreSQL developers already have open,
which is worth a look if that's what you're weighing

Source: “Index-Aware AI SQL Optimization in dbForge 2026.1”, Learning and Technology with Frank. Watch: https://www.youtube.com/watch?v=BMFCbA-T764.

Stop Sending Every SQL Query to Your Most Expensive Model — Build a Router Instead

David Murray — Tue, 15 Sep 2026 09:52:08 +0000

If you've built or integrated an AI SQL assistant into your stack, you've likely hit this wall: it works great in the demo, it works great in week one, and then usage scales and the model API bill scales right alongside it. The default fix — swap in a cheaper model everywhere — usually just trades your cost problem for a quality problem.

The better fix is architectural: route each query to the model tier its actual complexity requires.

Why one model tier doesn't work

SQL queries vary wildly in the reasoning they require. SELECT * FROM users WHERE id = 4471 and a cross-schema retention analysis using window functions are both "SQL," but they're not remotely equivalent workloads. Routing both through a frontier model is expensive overkill for the first one.

A practical tiering scheme:

Tier	Description	Examples	Model needed
1 — Routine	Simple, well-defined	SELECTs, lookups, basic CRUD, syntax fixes	Fast, low-cost model
2 — Moderate	Multi-step reasoning	Joins, subqueries, aggregations, optimization hints	Mid-tier model
3 — Complex	Deep schema reasoning	Cross-DB queries, window functions, execution-plan tuning, schema refactoring	Frontier model

Benchmarked figures put Tier 1 around $0.001/query versus roughly $0.03/query for a frontier model — a gap that scales linearly with volume. Tier 3 queries also need injected context (table relationships, foreign keys, indexes, dialect-specific syntax), which is expensive to carry through every request regardless of tier.

The pipeline: classify → route → execute → validate

Classification

This is the stage that determines whether the whole system works. Three implementation options:

Rule-based (regex/AST): Detect structural signals — table count, join depth, presence of window functions or subqueries. Fast, deterministic, zero model overhead. Handles the obvious cases well.

Lightweight classifier model: A small model trained specifically to estimate SQL complexity. Costs a fraction of a cent per call, which easily justifies itself by avoiding unnecessary frontier-model invocations. Can often run locally. Also useful for classifying natural-language prompts before SQL generation even happens.

Hybrid: Rules catch the clear cases for free; the classifier handles the ambiguous middle where structure alone doesn't tell you enough. This is the practical sweet spot for most teams.

Routing

Beyond tier, routing decisions should also account for:

Schema context requirements — queries needing foreign key/index awareness typically need a higher-capability model regardless of surface complexity.
Latency tolerance — autocomplete and inline suggestions have tight budgets; background jobs don't.
Classifier confidence — low confidence should bias toward routing up. A bad downgrade often triggers a retry, and retries are more expensive than getting it right the first time.

Validation

Post-execution checks confirm syntax correctness, sane result shapes, and schema consistency. Failures trigger escalation and a rerun at a higher tier.

A real implementation detail worth knowing

While building schema-aware capabilities into Devart's dbForge AI Assistant, the team found that classification accuracy depended heavily on schema context — not just query structure. Queries with ambiguous table names or implicit relationships were reliably misclassified as simple and sent to models that couldn't actually resolve them correctly. The fix: feed the classifier schema metadata alongside the query itself, not just the syntax tree.

Metrics that tell you if the routing is actually working

Don't just track average cost — it hides problems.

Cost per query, by tier. A blended average can look fine while masking a system that's routing 50% of queries to the wrong tier.
Escalation rate. The percentage of Tier 1/2 outputs that fail validation and need rerouting. Keep it under 5%; above that, retrain the classifier or give it more schema context.
Latency impact. Classification and routing overhead should add no more than 50–100ms.

Watch for the escalation tax: a misrouted query means a classifier call + initial model call + failed validation + reroute + second model call. Stack enough of those and you can end up paying more than if you'd just routed to the frontier model directly. Track escalation rate alongside cost per call, not in isolation.

Where the ROI ceiling sits

Well-tuned routing reportedly delivers 40–60% inference cost reduction while keeping escalation under 5% and preserving quality on complex queries. Pushing past that generally requires self-hosting smaller models for Tier 1 traffic — workable, but it adds real operational overhead (infra, monitoring, model lifecycle) that not every team needs to take on.

TL;DR for implementation

Build the classifier before you finalize the model lineup — it's the highest-leverage piece.
A hybrid classifier (rules + lightweight model) gets you most of the savings without excess complexity.
Feed the classifier schema metadata, not just query syntax — this matters more than it looks like it should.
Design validation logic before you lock in classification thresholds.
Track escalation rate as your primary quality signal.
As local inference gets cheaper, the payoff from correct tiering only grows — the cost gap between tiers widens, not shrinks.

This piece draws on an original analysis published on Unite.AI by Victor Horlenko, Head of AI Innovations at Devart.