The queries that cost you money usually aren't the ones anyone complains about. A dbt model ships to prod looking fine, then scans ten times the data it needs on every scheduled run for the next six months… Nobody notices, because nothing is broken. It's just quietly expensive.
The ones people do notice are bad enough: a model that used to build in two minutes now takes twenty. If someone asks why, nobody really knows.
But the information needed to spot these issues and answer the questions does exist: your warehouse produces it every time it runs a query. The problem is that almost nobody reads that output, because it was never written for humans.
That changes with the new Profile this query feature in Power User for dbt. One click sends your query to Altimate Code, which runs the warehouse's own diagnostics, reads the output, and tells you in plain language what the query is actually doing and where it's going wrong.
Why slow SQL is so hard to debug
In a cloud warehouse, SQL is a request, not a set of instructions. You describe the result you want. The warehouse decides how to get it.
That decision-making is invisible. Two queries that look almost identical can behave completely differently. One might read a few thousand rows. The other might scan an entire ten-billion-row table because a filter was written in a way the warehouse couldn't use.
You can't see this by reading the SQL. The SQL describes what, not how. And in modern cloud warehouses, how is exactly where the time and money go. Compute is billed by usage. A query that scans more data than it needs isn't just slow. It's expensive, every single time it runs.
Most dbt users respond to slow queries the only way they can: by guessing. Rewrite a CTE. Add a filter earlier. Try an incremental model. Sometimes it helps. Often it doesn't, because the guess didn't match the actual problem.
What an execution plan actually tells you
If you know how to ask, warehouses will tell you exactly how they run a query. Ask with a command like EXPLAIN, and you get back an execution plan: the warehouse's step-by-step strategy. Which tables it reads. How much data it expects to scan. How it joins tables together. Where it filters. What each step is estimated to cost.
Some databases go further. EXPLAIN ANALYZE (in Postgres, for example) actually runs the query and reports real numbers: how long each step took, how many rows actually flowed through, whether the work fit in memory.
This is the "ground truth" of query performance. If your query is slow, the reason is in the execution plan.
So why does nobody read them? Three reasons.
They're dense. A plan for a moderately complex query can run to hundreds of lines of nested operators, cost units, and internal jargon.
They're inconsistent. Snowflake, BigQuery, Postgres, and Databricks each format plans differently, use different terminology, and even use different commands to produce them.
They assume expertise. Reading a plan well means knowing what a hash join is, why "estimated rows: 100, actual rows: 4,000,000" is alarming, and which operators are red flags. That's a database performance skill set, not an analytics engineering one.
Warehouse execution plans are like an X-ray of your query: Incredibly informative… if you happen to be a radiologist.
What Altimate Code does differently
Altimate Code is an open-source AI coding agent built for data work, with a live connection to your warehouse. That last part is the key. It doesn't just look at your SQL. It can run the diagnostic commands your warehouse supports, get the real plan back, and interpret it.
In other words: it reads the X-ray for you.
Because it knows the differences between warehouse dialects, the same button works whether you're on Snowflake, BigQuery, Postgres, or something else. You don't need to remember which explain command your warehouse uses or what its plan format looks like. (The exact diagnostics available do vary by warehouse. Some expose richer runtime detail than others, so the depth of the profile depends on what your database can report.)
The dbt profile query workflow
The whole thing takes one click.
Step 1: Run a query in Power User for dbt, as you normally would.
Step 2: When results load, click "Profile Query" in the query results panel toolbar.
Step 3: Altimate Code chat opens with your SQL and a profiling prompt already in place.
Step 4: The agent runs or interprets the relevant warehouse diagnostics — the execution plan, and runtime statistics where available.
Step 5: You get back plain-language findings: what the query is doing, where the time and cost are going, and what to try next.
There's also "Explain with Altimate Code" in the SQL tab, which does something related but different. More on that distinction below.
What dbt Query Profiler can actually find
Here are the kinds of problems that hide in execution plans, and what a profile might surface. These examples are deliberately simple; real findings depend on your data and your warehouse.
The full table scan
select
order_id,
customer_id,
order_total
from analytics.fct_orders
where date(created_at) = '2026-08-03'
This looks fine. It filters to a single day. But wrapping created_at in date() can prevent the warehouse from using pruning — its ability to skip chunks of data that can't possibly match the filter. Instead of reading one day's worth of data, it may read the whole table and check every row.
A profile of this query might surface something like:
the plan shows a scan of the full table rather than a pruned range; the date() function on the filter column is likely preventing partition pruning; rewriting the filter as a range on the raw column should let the warehouse skip most of the data:
where created_at >= '2026-07-20'
and created_at < '2026-07-21'
Same result. Potentially a small fraction of the data scanned.
The join that explodes
select
c.customer_id,
count(*) as event_count
from dim_customers c
join fct_events e
on c.customer_id = e.customer_id
where e.event_date >= '2026-07-01'
group by 1
Suppose fct_events is huge, and the plan shows the join producing 200 million intermediate rows before the date filter is applied. That's a filter applied too late: the warehouse did an enormous amount of join work, then threw most of it away.
A profile might point out that the row count balloons at the join step, and suggest filtering the events table first (for instance, in a CTE) so the join only touches July's events. The output is identical; the work is not.
The dbt row estimate that's wildly wrong
Warehouses plan queries using row estimates: guesses about how many rows each step will produce, based on statistics about your data. When those guesses are badly wrong (i.e.: the plan expected just 100 rows and got 4 million) the warehouse may have picked a join strategy or memory allocation that made sense for 100 rows and falls over at 4 million.
This is one of the most common causes of "this query is sometimes fine and sometimes terrible," and it's essentially invisible without looking at a plan. A profile can flag the mismatch and point at the step where the plan's assumptions diverged from reality, which is often the first real clue to stale statistics or a skewed join key.
The expensive aggregation
A count(distinct user_id) over a billion rows, or a group by on a high-cardinality column, can dominate a query's runtime, sometimes spilling work to disk when it doesn't fit in memory. The plan shows this. A profile can identify that the aggregation step is where the time goes and suggest alternatives worth testing, like pre-aggregating in an upstream model or, where approximate results are acceptable, an approximate distinct count.
Explain vs. Profile: what's the difference?
Power User for dbt now gives you two related (but different) tools:
Explain this query answers: what does this SQL do? It reads the query and describes the logic: the joins, the filters, the transformations. It's great for understanding unfamiliar code, reviewing a teammate's model, or onboarding onto a project. It doesn't need to touch your data.
"Explain with Altimate Code" describes the query's logic without touching the warehouse
The Explain panel breaking down joins, filters, and transformations
Profile this query answers: how does this query perform against my actual warehouse? It's grounded in diagnostic output from the database: the execution plan, real or estimated row counts, the actual strategy the warehouse chose. It can tell you things no amount of reading the SQL can, because the answer depends on your data: its size, its distribution, how it's clustered or partitioned.
"Profile this query" is grounded in the warehouse's actual execution plan
The Profile panel surfacing real row counts and cost data from the warehouse
This is also what separates Power User profiling from pasting your SQL into a general-purpose chatbot. A chatbot can only reason about the text of your query. It doesn't know that your events table is 3TB, that your filter isn't hitting the partition column, or that the optimizer's row estimate was off by four orders of magnitude. Those facts live in your warehouse, and profiling is what brings them into the conversation.
What health query profiling means in practice
Cost. In cloud warehouses, wasted scans are wasted money, compounded by every scheduled run. A model that scans ten times the data it needs isn't a one-time problem — it's a recurring line item. Profiling makes that waste visible while the query is still in front of you.
Speed. Faster queries mean faster dbt builds, faster CI, faster dashboards. The fixes that profiling points toward — earlier filters, prunable predicates, leaner joins — tend to be small edits with large effects.
Team productivity. Perhaps the biggest shift is who can do this work. Today, deep query tuning tends to bottleneck on whoever on the team can read plans. Profiling puts a first-pass diagnosis in every analytics engineer's hands. Instead of "this is slow, can someone look at it," the starting point becomes "the profile says the join is exploding before the filter — I'm going to try restructuring it."
One note on positioning: profiling doesn't guarantee a faster query, and it doesn't rewrite your models for you. What it does is close the gap between "this query is slow" and "here is what is likely causing it, and what to try next." It's still a judgment call when it comes to what to change (and whether the tradeoff is right for your model).
Try dbt query profiler today
Query Profiler is live in Power User for dbt today. You will find the docs here. You can access the feature as follows:
Profile this query: in the query results panel toolbar, visible once query results are loaded. Run a query, then click it.
Explain with Altimate Code: in the SQL tab, for when you want to understand what a query does rather than how it performs.
Both open Altimate Code chat with the context already loaded, so you can keep asking follow-up questions: "why is this step expensive?", "What would happen if I filtered earlier?", "Show me the rewritten version."
If you're already running Power User for dbt, update to the latest version and try it on the slowest model in your project. You may find the answer has been sitting in your warehouse all along, just waiting for someone to read it.
Altimate Code and Power User for dbt (available on VS Code) is open source. Have feedback on profiling? We're actively improving dialect coverage and would love to hear what you find.
