Materialization
How dbt persists a model in the warehouse — as a view, a table, an incremental table, or ephemeral (inlined CTE). Chosen per model to balance freshness, cost, and query speed.
A materialization is dbt's strategy for turning your SELECT into something in the warehouse. The four built-ins: `view` (no storage, always fresh, slower to query), `table` (rebuilt each run, fast to query), `incremental` (append/merge only new rows), and `ephemeral` (not persisted at all — inlined as a CTE into downstream models).
The choice is a cost-versus-speed trade-off. Views are cheap but push compute to query time; tables cost storage and build time but are fast to read; incremental tables are for large facts where full rebuilds are too expensive.
A common pattern: views for staging, tables for marts, incremental for the few enormous fact tables. Set it with `{{ config(materialized='table') }}` per model or as a folder default in `dbt_project.yml`.
Materialization is the main lever you have over the cost/speed/freshness trade-off in a dbt project. Defaulting everything to one strategy is how teams end up with either huge warehouse bills or painfully slow dashboards.
Choosing materializations deliberately per layer is a hallmark of a well-run project.
- Materializing everything as tables, inflating build time and storage cost.
- Using views for heavy marts that get queried constantly, pushing expensive compute to every dashboard load.
- What are the dbt materialization types?
- view, table, incremental, and ephemeral. Views are cheap and fresh; tables are fast to query; incremental processes only new rows; ephemeral inlines the model as a CTE without persisting it.
Go deeper in the dbt for Analytics Engineers hub.
Learn this by building, not memorizing.
Definitions get you the vocabulary. The platform gets you the skill — graded exercises, real projects, and a portfolio capstone.