dbt Cost Optimization Package
A dbt package that analyzes your data platform's compute, storage, and query patterns to identify optimization opportunities and produce actionable recommendations.
Supported platforms
What you'll get
Quick-use commands
On-demand optimization checks you can run with dbt run-operation, with no models to build first. Currently available for Snowflake:
| Command | What it finds |
|---|
find_table_clustering_candidates | Tables that would benefit from clustering |
suggest_clustering_keys | The best clustering key columns for a specific model |
find_table_materialization_candidates | Views queried often enough to materialize as tables |
find_incremental_materialization_candidates | Large, slow-building tables suited to incremental models |
find_warehouse_sizing_recommendations | Warehouse sizing changes (scale up or down, multi-cluster, Gen2) |
find_spillage_candidates | Models whose builds spill to local or remote storage |
find_expensive_dbt_queries | The most expensive recurring dbt queries by projected annual cost |
For example: dbt run-operation find_table_clustering_candidates --args '{lookback_days: 14}'. See docs/snowflake/macros.md for every command's arguments.
Snowflake
The package produces gold-layer views: dashboard-ready outputs that surface ranked, prioritized recommendations.
| View | Audience | What it shows |
|---|
vw_snowflake__top_recommendations | Executives / leads | Top-priority recommendations across all domains, deduped per entity |
vw_snowflake__dbt_model_optimizations | dbt engineers | Actionable model changes: clustering keys, materialization, incremental configs |
vw_snowflake__warehouse_optimizations | Snowflake admins | Warehouse config changes: auto-suspend, scaling, sizing — with linked model context |
vw_snowflake__optimization_backlog | Sprint planning / agents | Full inventory of all signals (all priority tiers) for ticket creation |
vw_snowflake__top_expensive_queries | Cost owners | Top 10 expensive queries enriched with root-cause co-signals |
vw_snowflake__top_spillage_models | Performance engineers | Models causing the most memory spillage, with dbt platform run traceability |
vw_snowflake__top_queried_models | Platform engineers | Most-queried models (downstream consumption pressure) |
vw_snowflake__cross_domain_insights | Architecture leads | Multi-signal correlation (why issues co-occur on the same model) |
vw_snowflake__cost_savings_summary | Dashboards | KPI tiles: total opportunity per domain |
vw_snowflake__user_level_cost_attribution | Cost owners | User-level cost attribution for chargeback |
vw_snowflake__ai_optimizations | AI/ML teams | Cortex model cost, token efficiency, agent spend |
Each recommendation includes a priority_tier, a per-entity relative ordering:
- P1 = do this first (highest in the optimization hierarchy for this model/warehouse)
- P2 = do this second (after P1 is applied)
- P3+ = deferred (waiting for higher-priority fixes to resolve the symptom)
Priority cascades naturally: when you apply a P1 fix (e.g., add a clustering key) and rebuild, the signal disappears and P2 promotes to P1 automatically.
Databricks, BigQuery, and Redshift (Beta)
These platforms produce recommendations at the fact-model layer. Dashboard views and charts like Snowflake's are coming soon.
| Platform | Recommendations |
|---|
| Databricks | Liquid clustering, OPTIMIZE, table and incremental materialization, snapshot optimization, and model run trends, plus a per-model rollup (vw_databricks__recommendations_by_model) |
| BigQuery | Table clustering candidates and clustering key recommendations |
| Redshift | Sort key and distribution key recommendations, table and incremental materialization, incremental config, and VACUUM and ANALYZE candidates |
See each platform's docs for model details and configuration.
Installation
Works on dbt v2 (the dbt Fusion engine) and dbt v1 (dbt-core 1.10 and later).
Add to your packages.yml:
packages:
- package: dbt-labs/dbt_cost_optimization
version: [">=1.0.0", "<2.0.0"]
Then run:
dbt deps
Getting started
After installation, see your platform's documentation for required permissions, configuration, and quick start commands:
Configuration
The package is opt-in: its models only build where you turn it on.
Turn the package on with environment variables
The settings that switch the package's models on and off are environment variables. They work the same on dbt v1 and dbt v2, so nothing changes when a project moves from one to the other. Set them only in the environments or jobs that should build the package (your shell, CI, or a dbt platform environment or job):
This is the beginning of the README. Read the rest at the original. Read the full README ↗
