Ask Claude about your database.

Before you start

You'll need an Anthropic API key (get one at console.anthropic.com if you don't have one) and at least one working database connection. Any tier works; Ask depends on the key you add, not on which subscription tier you're on.

Step by step

1. Go to Settings → AI Assistant and paste your key into Anthropic API Key.
2. In the SQL Editor, click Ask (or press ⌘L).
3. Type a question. Optionally attach Current query, Selection, or Last error.
4. Read the one-sentence answer and the SQL underneath it.
5. On any SQL Claude writes, use Insert into editor, Run, or Watch this.

A worked example

On a Postgres connection for a support ticketing app, ask: "write a query for daily row counts over the last 30 days in tickets." A reasonable answer:

SELECT date_trunc('day', created_at)::date AS day,
       count(*) AS tickets_created
FROM public.tickets
WHERE created_at >= current_date - interval '30 days'
GROUP BY 1
ORDER BY 1;

Click Run to see it against your real data, or Insert into editor if you want to modify it first.

Check it worked

The panel returns a one-sentence answer plus the SQL it ran, and step cards showing which tables and columns it checked along the way. If those look right and the numbers match what you'd expect, you're set.

Troubleshooting

Other prompts worth trying

"What tables are in this dataset, and what do they look like" is a good first question on any new connection. "Why did my last query fail" works best with Last error attached. Once you have an answer you trust, thumbs-up it so it becomes a verified query the panel can reuse.

Attaching context instead of describing it

Typing out an error message from memory loses detail. Attaching Last error hands the panel the exact text Postgres, Snowflake, or whichever database you're on actually returned, which tends to produce a more specific fix than a paraphrased description of the same failure would.

A second worked example: fixing a broken query

Say a Snowflake query fails with SQL compilation error: Object 'ORDERS' does not exist because the table is actually named orders and the connection's default schema wasn't set. Attach Last error and ask what happened; the panel checks the schema, finds the case mismatch and the missing schema qualifier, and offers analytics.public.orders as the corrected reference along with an explanation of why the original failed.

Reading the step cards

Expand a step card to see exactly which table or column the panel checked at that point, and, for a result-based question, which prior rows it read. On a schema with a lot of similarly named tables, this is the fastest way to confirm it picked the one you meant rather than a near-duplicate from an older migration.

Following up instead of starting over

If the first answer is close but not quite right, say so directly, "that's right except I only want orders from the last 7 days," rather than retyping the whole question. The panel keeps the schema context and the prior query, so a follow-up is usually a small edit, not a fresh exploration.

What this tutorial doesn't cover

Watching the query for changes over time is a separate step, covered in how Watch This works. Scheduling it to run every morning is covered in the scheduler tutorials. This tutorial is just getting a trustworthy answer once.