0
0
dbtdata~10 mins

Materializations (view, table, incremental, ephemeral) in dbt - Step-by-Step Execution

Choose your learning style9 modes available
Concept Flow - Materializations (view, table, incremental, ephemeral)
Start dbt model run
Check materialization type
View
Create/View
Model data ready for next step
dbt runs models by choosing a materialization type, then creates or updates data accordingly.
Execution Sample
dbt
model.sql:
-- materialization: incremental
select * from source_table
where updated_at > (select max(updated_at) from {{ this }})
This incremental model adds only new or updated rows since last run.
Execution Table
StepMaterialization TypeActionData OutputNotes
1ViewCreate or replace SQL viewVirtual table with fresh dataNo data stored, always fresh
2TableCreate or replace physical tableFull data snapshot storedData stored on disk, refreshed fully
3IncrementalAppend or update rows in tableOnly new/changed rows addedEfficient for large datasets
4EphemeralNo table created, used in SQL compilationTemporary CTEs in queriesNo physical table, fast for small logic
5EndModel materializedData ready for downstream useProcess complete
💡 All materializations complete, data ready for next steps
Variable Tracker
VariableStartAfter Step 1After Step 2After Step 3After Step 4Final
materialization_typeNoneViewTableIncrementalEphemeralSet per model
data_storageNoneVirtual (view)Physical tableUpdated tableNone (CTE)Depends on materialization
data_freshnessUnknownAlways freshSnapshot at runPartial updateDepends on queryReady for use
Key Moments - 3 Insights
Why does an incremental model not recreate the whole table every run?
Because incremental materialization appends or updates only new or changed rows, as shown in execution_table step 3, making it efficient for large data.
What happens to data in an ephemeral materialization?
No physical table is created; ephemeral models are compiled as CTEs inside other queries, so data exists only during query execution (execution_table step 4).
How is a view different from a table in dbt materializations?
A view is a virtual table that runs the query fresh each time (step 1), while a table stores data physically and is refreshed fully on each run (step 2).
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what action does the incremental materialization perform at step 3?
ACreate or replace SQL view
BAppend or update rows in table
CCreate or replace physical table
DUse temporary CTEs in queries
💡 Hint
Check execution_table row with Step 3 under 'Action' column
According to variable_tracker, what is the data freshness state after Step 2 (Table materialization)?
AAlways fresh
BPartial update
CSnapshot at run
DDepends on query
💡 Hint
Look at 'data_freshness' row, column 'After Step 2'
If you want no physical table created and only temporary logic in queries, which materialization should you choose?
AEphemeral
BIncremental
CView
DTable
💡 Hint
Refer to execution_table step 4 and variable_tracker 'data_storage' after Step 4
Concept Snapshot
dbt materializations control how models store data:
- view: virtual table, always fresh
- table: full physical table, replaced each run
- incremental: update/append rows, efficient for big data
- ephemeral: no table, used as CTEs in queries
Choose based on data size and freshness needs.
Full Transcript
In dbt, materializations decide how your data models are stored and updated. Views create virtual tables that run fresh queries every time. Tables store full snapshots of data and replace them fully on each run. Incremental materializations add or update only new or changed rows, saving time on large datasets. Ephemeral models don't create tables but compile as temporary query parts (CTEs) inside other models. This flow helps dbt efficiently manage data transformations depending on your needs.