Paste a query, get a plain-English explanation.

Before you start

A query you want explained, and your own API key added under Settings → AI Assistant. Ask works with Claude, GPT-6, Gemini or Grok, whichever provider's key you've added.

Steps

1. Go to Settings → AI Assistant and add an API key for the model you want to use.
2. In the SQL Editor, select the query (or open it) and click Ask, or press ⌘L.
3. Attach Current query or Selection.
4. Ask a question like: "Explain what this query does, plain English, step by step."
5. Read the answer and its step cards, or type /verbose for full reasoning.

A worked example

A multi-join Databricks query that's less obvious at a glance than it looks:

SELECT o.order_id, c.customer_name, SUM(oi.quantity * oi.unit_price) AS order_total
FROM sales.gold.orders o
JOIN sales.gold.customers c ON o.customer_id = c.customer_id
JOIN sales.gold.order_items oi ON oi.order_id = o.order_id
WHERE o.order_date >= DATE_SUB(CURRENT_DATE(), 30)
GROUP BY o.order_id, c.customer_name
HAVING SUM(oi.quantity * oi.unit_price) > 500;

Attach it as Current query and ask for an explanation. Because Ask can see the connected schema, the answer breaks it down in terms of your actual tables: it joins orders to customers to get a name, joins to order_items to get the line-item quantities and prices, filters to orders from the last 30 days, groups by order, and keeps only orders whose total is above 500, that last part being the HAVING clause, which filters on an aggregate rather than a raw column the way WHERE does. Step cards under the answer show which tables and columns it actually looked at to write that explanation.

Why this beats pasting the query into a general chat tool

A generic AI chat product can explain SQL syntax fine, JOIN, GROUP BY, HAVING, in the abstract. What it can't do is tell you that c.customer_name in your specific schema comes from a table with three million rows and a non-unique index on customer_id, because it's never seen your schema. Ask has, because it's running against the same connection your query runs against.

A shorter example, and a follow-up question

Not every query needs the full walkthrough. For a short one:

SELECT region, COUNT(DISTINCT user_id) AS active_users
FROM app.sessions
WHERE session_start >= CURRENT_DATE - 7
GROUP BY region;

type /brief before your question for a one-line answer instead of a full breakdown: "counts distinct users per region who had a session in the last 7 days." If that's not enough, follow up in the same thread, "why DISTINCT and not just COUNT(*)," and it answers in context without you re-attaching the query.

What this doesn't do

This explains what a query does, it doesn't evaluate whether it's slow or suggest a faster version. For that, see asking why a query is slow instead, a related but separate question.

Explaining someone else's query, not one you wrote

This works just as well on a query you inherited as one Ask wrote itself. Open an old script or a query a former teammate left behind, select it, attach it as Selection, and ask the same question. It reads the SQL exactly as written and explains what it actually does against your current schema, which sometimes surfaces something worth knowing on its own: a join to a column that's since been renamed, or a filter that no longer matches any rows.

Check it worked

A good explanation names your actual table and column names, not generic placeholders, and the step cards list the specific tables it read to answer.

A habit worth building

Explaining a query before you run it against production is a cheap sanity check, especially for one you didn't write. It catches the case where a query does something subtly different from what its name suggests, a "monthly_active_users" view that's actually counting sessions, not distinct users, before that difference costs you an afternoon downstream.

Troubleshooting