Ephemeral Materialization
Unlike other materializations, ephemeral models don't create database objects. Instead, dbt incorporates the model's code into dependent models using Common Table Expressions (CTEs).
This means:
No physical tables or views are created
Code is integrated into downstream models
Logic can be reused across models
CTEs are prefixed with
__dbt__cte__
Ephemeral models are ideal for lightweight, reusable transformations that don't need to be queried directly.
Working with Ephemeral Models
Let's understand ephemeral models through a simple example:
When this model is referenced:
No table or view is created
The code becomes a CTE in downstream models
The logic is recomputed each time it's used
When to Use Ephemeral Models
Ephemeral models work best for:
Simple transformations (cleaning, filtering)
Early-stage models in your DAG
Light data preparation steps
Code that supports 1-2 downstream models
Configuration
Model-Level Configuration
Performance and Usage Guidelines
Advantages and Limitations
🧹 Reduces database clutter
🚫 Can't query directly
♻️ Enables code reuse
⚠️ No model contracts support
📦 No storage overhead
🔍 Harder to debug
🔄 Flexible logic updates
🛠️ Limited operational use
When to Change Materialization
Consider a different materialization when you:
Need to query the model directly
Have complex transformations
Support many downstream models
Require model contracts
Best Practices
Keep It Simple: Use for lightweight transformations only
Limit Dependencies: Best for 1-2 downstream models
Consider Debugging: Use sparingly to maintain query clarity
Ephemeral models are powerful for code organization but should be used judiciously. Consider views or tables for more complex or widely-used transformations.
Last updated
Was this helpful?