Query & ask the AI

Once a database is connected, you can explore it two ways: write SQL yourself in the IDE, or just ask the AI. Both run through the same read-only, auto-capped path.

The SQL IDE

Open a connection to land in its workspace — a SQL client built for exploring that one database:

Schema browser (left) — every table and view Catalyst found. Expand a table to load its columns, types, and keys (loaded lazily, so even a 4,000-table database opens instantly). A primary-key column is flagged with a key icon, a foreign key with a link icon. Hover a table and click SELECT to drop a starter query into the editor.
Query tabs — open as many as you like; each tab is an independent query with its own editor content and its own results.
Editor — write a SELECT and press Run (or ⌘/Ctrl+Enter).
Results grid — rows come back in a table with a sticky header. Very wide cells are truncated for display (hover to see the full value); a banner tells you honestly when a result hit the row cap.

Finding a table

The schema browser’s filter works like a SQL LIKE:

Multiple terms (separated by spaces or commas) are OR’d — apr athlete matches tables containing either.
% or * is a wildcard — apr% matches tables that start with apr.

On a large database the browser shows a capped page and filters server-side to reach the rest, so typing a term is how you find a specific table in thousands.

Getting the data out

The results toolbar exports the current result set:

Export as CSV — a UTF-8 file (opens cleanly in Excel, accents and all).
Export as Excel (.xlsx) — a real spreadsheet.
Copy as TSV — copies the rows to your clipboard, ready to paste into a spreadsheet.

The exact SQL that ran is part of every result — including the LIMIT Catalyst added — so you can copy a portable, runs-anywhere query.

Asking the AI about your data

Every database carries a built-in assistant that already knows its schema and dialect, so it writes queries with your real column names and the right SQL flavor — and it’s bound to the same read-only, auto-capped path everything else uses, so it’s structurally incapable of writing data or pulling a whole table.

Draft vs Agent

The assistant in the IDE has a Draft / Agent toggle (Draft is the default). Both modes are fully capable of inspecting the schema; they differ in what they do with the query:

Draft — the assistant writes a query into a new editor tab without running it. This is the token-cheap path: ask “give me a query for monthly revenue in 2025 by product category” and it hands you the SQL to review and run yourself. Use it when you want a query, not the answer.
Agent — the assistant runs read-only queries and analyzes the results. Use it when you want the answer: “what was our monthly revenue in 2025, and where did it dip?”

Flipping the toggle re-seeds the conversation so the new bias takes effect on your next message.

Attaching a database to a chat

You can also attach a database to a normal chat — the “ask AI about my data” entry point (the Ask AI button on a connection does exactly this). The model gets the connection’s schema and the read-only SQL tool, and the chat runs in the full agentic mode — so you can ask data questions in the middle of an ordinary conversation and it explores the tables and runs the queries to answer.

How the AI works with a database

Behind any of those entry points, the model uses one built-in tool and follows a disciplined loop. With agentic mode on:

Find what’s there — list the databases you’ve connected, with their dialect and status.
Explore the tables — list a source’s table and view names, or search by keyword on a big database instead of dumping the whole catalog.
Look closely — describe the specific tables it needs (their columns, types, keys, and a few sample rows) before writing a join, so it uses real column names.
Answer the question — draft a query into your editor, or run a read-only SELECT and read the rows back.

Each call streams into the conversation, so you see which tables it looked at and the exact query it ran — you can trust the answer or correct it. Schema is revealed progressively: even a database with thousands of tables won’t flood the conversation, because the model only loads the slice it needs.

From query to analysis

When a question needs real computation — a chart, a statistical breakdown, a join across results — the model can hand a query’s rows to the run-code tool and work with them in Python as a table. So a single request can go from “pull the orders” straight to “now plot revenue by week and flag the outliers” without you exporting a CSV in between.

In workflows and prompts

The same read-only SQL tool is available beyond chat:

A workflow SQL node runs a parameterized query as one step of a pipeline — pull yesterday’s numbers, summarize them, email the result. The tutorial builds one that an app calls live.
A prompt can carry SQL bound to a data source, so selecting it sets the model up to work against the right database from the first message.

When the model needs help with a cryptic schema, a data-source guide teaches it which tables mean what.