- What it is. A Profile Query button in the Query Results panel. It sends your compiled SQL to Altimate Code with the prompt written. Altimate Code then runs its own SQL tools on it.
- Who it is for. Analytics engineers with a slow dbt query, or a model they cannot fully trust. The model returns rows, but is it right in every case?
- What you get. A report that leads with correctness bugs, lists the anti-patterns and ranks the fixes. You apply them in the same chat.
A slow dbt query is easy to notice. A wrong one is not. A model can return plausible rows for months and still hide a bug in one branch of a CASE expression. Reviewing it by hand means reading every CTE. Asking a chatbot means writing a prompt that names every check you care about. You only find the checks you thought to ask for. That gap grows as more of your SQL comes from an AI assistant.
Click Profile Query Once the Query Returns Results
Run the query the way you already do, with Cmd+Enter on a Mac or Control+Enter elsewhere. Once results come back, a Profile Query button becomes available in the Query Results toolbar. It appears only when there is data to profile.
Clicking it opens an Altimate Code chat named after your file. The full prompt is already written. The SQL it sends is the compiled query, which is what your warehouse runs. It falls back to the raw text only when no compiled version exists.
The prompt asks for four things, in this order:
| Order | Check | Example finding |
|---|---|---|
| 1 | Correctness | A NULL case that returns 0 |
| 2 | Performance | An aggregation before a join |
| 3 | Cost | A full scan the warehouse cannot prune |
| 4 | Best practice | SELECT * in the outer query |
Read the Correctness Bug Before the Style Warnings
Altimate Code calls its analyze and rewrite tools, which add a deterministic check on top of the model's answer. The report puts correctness first. On the customers model it found that two columns handle the no-orders case differently.
Of 100 customers, 38 never placed an order. The model reports a 0% return rate for all 38, when the right value is NULL. The sql_analyze tool then lists three more findings:
SELECT *in the outer query.- A division by a column that can be zero.
- An aggregation before a join.
Apply the Ranked Fixes in the Same Session
The report ends with recommendations ranked by impact. Fixing the NULL handling comes first, because it affects 38% of rows. Replacing SELECT * with an explicit column list comes second. The report also names a pattern to keep. Here, the pre-aggregate-then-join pattern needed no rewrite.
Ask Altimate Code to patch the model, or ask a follow-up about any finding, in the same chat. For the rest of the panel, see the Query Results panel guide.
Install the dbt VS Code extension
Frequently Asked Questions
Usually because of something the SQL text does not show. A filter may be written so the warehouse cannot prune on it. A join may multiply rows before its filter runs. Profile Query reads the compiled SQL with Altimate Code's tools and names the cause in plain English.
In the Query Results panel toolbar. It only appears once a query has returned results, so run the query first. If you have results and no button, the panel is showing a view other than the default query result.
Correctness first, then performance, cost and best practices. In the demo it found a NULL handling bug that affected 38 of 100 customers. It also flagged SELECT * in the outer query, a division by a column that can be zero and an aggregation before a join.
The compiled SQL, and it falls back to the raw query text only when no compiled version is available. This is the right choice for review work, because the compiled query is what your warehouse runs.
A chatbot reasons only about the text you pasted and the checks you thought to name. Profile Query writes the prompt for you, and Altimate Code adds deterministic tools such as sql_analyze. Those tools return the same findings for the same SQL, whatever words you would have used.
Yes, when you ask. Altimate Code's sql_explain tool runs your warehouse's own EXPLAIN and reads the plan back. Snowflake does not support EXPLAIN ANALYZE, so there you get the plan and its estimates rather than measured runtimes.
The most common cause is bind placeholders. The warehouse cannot explain a query that still carries ?, :name or $1. Replace each placeholder with a real value, run the query again, then click Profile Query.
No. It reports the findings and asks whether you want the fixes applied. You decide what changes in your model file. You can also ask follow-up questions about any finding before you accept a fix.
