Introducing SQL Debug: paste a failing query, get a fixed one

Today we’re launching SQL Debug — a dedicated mode inside ErrorLens that takes a failing query, optionally accompanied by the database error and your schema, and returns three things: a corrected query, an explanation of what changed, and a typed list of issues (syntax, schema, semantic, performance, security, style).

The general-purpose error analyzer already handled SQL errors. So why a separate mode?

Generic analysis is the wrong shape for query bugs

Our standard analyze an error log response gives you rootCause, suggestedFix, and a stack-trace-flavoured walkthrough. That’s exactly right for a Java NPE or a Python KeyError. It’s the wrong shape for a broken SQL query.

When you’re debugging a query, the thing you actually want is the corrected query — copy-pasteable, indented, in your dialect. A multi-paragraph “the suggested fix is to add a JOIN clause and consider adding a covering index” is technically correct but operationally useless. We saw users running our error-mode output, then immediately asking the AI to just give me the fixed query in a follow-up.

SQL Debug solves that directly. Every response carries a fixedQuery string that the UI renders in a copy-button-equipped block. The narrative explanation lives next to it for context, but the artifact you’re going to actually use is one click away.

What you give it

Three fields, two of which are optional:

• Query (required). The query that’s misbehaving.
• Database error (optional). Whatever your client surfaced — ERROR: column "o.total" does not exist, ORA-00904, SQLSTATE[42S22], etc. The more specific, the faster the AI gets to root cause.
• Schema / DDL (optional). A few CREATE TABLE statements for the relevant tables. Without this, the AI has to guess at column types from the query — usually fine, but for ambiguous bugs (is customer_id a UUID or a BIGINT?) it can mis-diagnose.

You also pick a dialect from the dropdown — PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, BigQuery, Snowflake, Redshift, or auto-detect. Auto-detect works well when the error message has a clear giveaway (ORA-, SQLSTATE, (error) READONLY); for ambiguous cases we recommend setting it explicitly.

What you get back

A response object with the standard severity / summary / root-cause fields plus four SQL-specific ones:

• fixedQuery — the corrected query, formatted with newlines and uppercase keywords.
• explanation — a short walkthrough of what changed and why.
• issues[] — typed list. Each entry has a kind (one of the six categories above), a description, and an optional line number when the AI can localise it.
• performanceNotes — present when the AI spotted indexing / planner / rewriting opportunities. Omitted otherwise so the UI doesn’t render an empty card.

A worked example

Suppose you have:

SELECT u.name, COUNT(o.id)
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > NOW() - INTERVAL '30 days';

Postgres returns:

ERROR: column "u.name" must appear in the GROUP BY clause
       or be used in an aggregate function

SQL Debug returns a fixed query with the missing GROUP BY u.id, u.name, an explanation that calls out the SQL standard requiring non-aggregated columns to be grouped, and an issues entry of kind semantic. It also flags a performance issue: the query will scan all of orders via the LEFT JOIN; an index on orders(user_id) would let the planner do an index-only nested loop.

What it’s not

SQL Debug is not a query optimizer in the traditional sense. It doesn’t run EXPLAIN ANALYZE against your database, doesn’t see your real cardinality statistics, and won’t catch issues that only surface under specific data distributions. Think of it as the senior database engineer who reads the query, the error, and the schema, and tells you the most likely fix in 8 seconds — not as a replacement for a real performance investigation when one is warranted.

Try it

Open Dashboard → New Analysis and switch to the SQL debug tab. Available on every plan including Free.