DEV Community: David Murray

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.