In this lesson, you will learn how to trigger your transformation logic to materialize your dbt models as physical assets within your data warehouse.
Up to this point, you have focused on project setup, defining schemas, and writing modular SQL code using ref. However, until you execute these models, they exist only as logic—they haven't actually created any tables or views in your database. This is where dbt run comes in.
The Power of dbt run
When you run the command dbt run in your terminal, dbt parses your project, compiles your SQL code (injecting the correct database credentials and schema names), and executes that code against your warehouse.
By default, dbt materializes models as views. However, you can change this behavior in your configuration to materialize them as tables, which persists the data physically in your storage layer for better query performance.
Practical Execution
Suppose you have a model defined in models/orders_summary.sql. To materialize this model, you simply run:
dbt run --select orders_summary
When you execute this, dbt performs three major steps behind the scenes:
- Compilation: It converts your Jinja-wrapped SQL (like
{{ ref('raw_orders') }}) into pure, valid SQL for your specific warehouse. - Execution: It sends a
CREATE OR REPLACE TABLE/VIEWstatement to your database. - Tracking: It updates the internal dbt state so it knows the transformation has successfully occurred.
If you have many models, dbt run is intelligent enough to execute them in the correct order based on their lineage. If model_b references model_a, dbt will ensure model_a is created first. This dependency management is what makes dbt a powerful orchestration tool for your transformations, ensuring your data pipeline remains robust even as your project grows in complexity.
Key Takeaway: The dbt run command is the engine that converts your SQL transformation logic into live data assets inside your warehouse by handling compilation, dependency sequencing, and physical materialization.