dbt
⚙️ To enable this feature, make sure to complete the quick setup in Yuki’s dbt integration guide, it only takes a few minutes: https://github.com/YukiTechnologies/yuki-snowflake-dbt-tags
The dbt page provides full visibility into model-level cost and performance. Track how each job ran, identify which models consumed the most time or budget, and fine-tune performance by adjusting the Snowflake warehouse used for specific models and run types (full refresh or incremental).
Dashboard Overview
Execution Summary - a quick view of recent job runs with total execution time and cost. Spikes are easy to spot.
Model Timeline (Gantt) - for any run, see what model ran when and how long it took.
Model Drill-down - for a single model: last X runs with runtime and cost. From any row you can open the exact query in Snowflake (for deeper inspection).
Filters live in a top bar and apply across dbt while you browse (job selection, number of last runs, status, run type, etc.). Keep them simple: pick the job, choose how many runs to look at, and narrow if needed.

Optimize with model-level warehouse sizing
You can tune cost/performance per model, per job.
How to change a model’s size:
Open the model drill-down.
Choose Change warehouse size tab.
Select the target size.
Apply. The change is queued for the next job.
What you get back
Average runtime and average cost.
A Change History that records who changed what, when, and the impact (runtime/cost deltas after a few runs).

Changes Summary (job-level)
The Changes Summary tab centralizes all model-level warehouse size updates for a specific dbt job, giving you a single place to track what changed, when, and how it affected cost and performance.
Use it to:
Manage all model-level warehouse size adjustments in one view.
See who made each change, when it was applied, and whether it increased or decreased warehouse size.
Understand the impact - compare average runtime and cost before and after each change.
Columns include: Model name, run type, target size, change type (increase/decrease), number of runs used for analysis, average runtime and cost deltas, materialization type, and changed by (user).

Cost Breakdown
The Cost Breakdown tab gives you a clear, daily view of dbt spend and helps identify long-term trends or unusual spikes before they become issues. It connects execution data with cost insights, so you can understand where compute resources are going - and why.
What you’ll see
Stacked Daily Chart - visualize total dbt spend per day, broken down by job.
Materialization View - compare cost across materialization types (incremental, table, view).
User & Warehouse Filters - slice spend by users, warehouses, or domains to understand ownership and allocation.
Trend Indicators - quickly spot days or jobs that deviated from normal cost behavior.
How to use it
Detect recurring cost spikes and trace them back to specific jobs or models.
Monitor whether recent optimizations actually lowered costs over time.
Combine with the Changes Summary to correlate warehouse resizing with cost impact.
The Cost Breakdown view completes the dbt Page by providing the financial layer - connecting technical performance with real spend impact.

Optimization Workflows
The dbt page is designed for investigate → optimize → verify loops.
Investigate a spike
Spot the anomaly in Execution Summary.
Open that day’s Timeline to see which model took longer.
Drill down to Execution History for that model.
Open the query in Snowflake if needed.
Reduce recurring cost
In Changes Summary, focus on Incremental models.
Sort by Cost per run.
Downsize the top offenders.
Track runtime deltas in the Change History.
Why Use the dbt Page
Transparency - Know exactly which models are consuming time and money.
Granularity - Optimize at the model level, not just at the warehouse/job level.
Accountability - Change History shows who made what adjustments and their effect.
Control - Balance cost vs performance per model, per job, per run type.
Next StepNext Step
For a deeper look into workload behavior, execution trends, and efficiency insights, continue to: → Performance Page
Last updated