View Materialization

A view materialization creates a view in your data warehouse that represents the SQL query of your dbt model. Unlike tables, views don’t store data physically – they’re simply stored query definitions that run each time they’re accessed.

How View Materializations Work

When you materialize a model as a view, dbt creates or replaces a view in your warehouse. During each run, dbt:

Creates or replaces the view definition using your model’s SQL
Stores the query definition, not the actual data
When queried later, the view executes its underlying SQL on-demand

This means:

No physical data storage – just the query definition
Data is always up-to-date with source changes
Queries run the entire transformation each time
Build times are faster since no data is materialized

Under the hood, dbt executes a CREATE VIEW or CREATE OR REPLACE VIEW statement:

CREATE OR REPLACE VIEW "database"."schema"."my_view" AS (
    SELECT * FROM source_table WHERE condition = true
);

Views are ideal when you need real-time data or when build time is more important than query performance.

When to Use View Materializations

Views are particularly valuable for:

Use Case	Why Views Work Well
Real-time data needs	Views always reflect the latest source data
Staging/simple models	Low-complexity transformations perform well as views
Infrequently accessed data	Minimizes storage costs for rarely-used data
Rapid development	Quick iteration cycle during development

Configuring View Materializations

Views can be configured at both the model and project level.

Model-Level Configuration

-- In your model SQL file
{{
    config(
        materialized='view'
    )
}}

SELECT
    customer_id,
    first_name,
    last_name,
    email
FROM {{ ref('stg_customers') }}
WHERE status = 'active'

Project-Level Configuration

# In your dbt_project.yml file
models:
  your_project:
    staging:
      +materialized: view

This sets all models in the staging/ directory to materialize as views.

Performance Considerations

Views have different performance characteristics across warehouses:

Warehouse	View Characteristics
Snowflake	• Secure views option • Materialized views available • Query optimization
BigQuery	• Authorized views • Materialized views • Query caching
Redshift	• Late binding views • Materialized views • Query planning

To apply specific view configurations, use the config() function with appropriate parameters:

{{
    config(
        materialized='view',
        secure=true,
        bind=false
    )
}}

Advantages and Limitations

Advantages	Limitations
⚡ Fast build times	🐢 Slower query performance
🔄 Always reflects current data	⚠️ Resource-intensive for complex queries
💾 Minimal storage usage	⏱️ Each query recomputes the transformation
🔍 Shows exact lineage in queries	📊 Can create performance issues in BI tools

When to Consider Other Materializations

While views are powerful, consider alternatives when:

Query performance becomes critical (use tables)
Transformations are complex and compute-intensive (use tables)
View references lots of data but users only need recent records (use incremental models)
Transformation is only a stepping stone for a single downstream model (use ephemeral)

Best Practices

Default to Views: Start with views for most models and change only when needed
Staging Models: Keep staging models as views for flexibility
Query Optimization: Write efficient SQL to reduce runtime overhead
Monitor Performance: Watch for slow-running views and consider materializing as tables
Documentation: Clearly document performance expectations for view models

By using view materializations strategically, you can create flexible, always-up-to-date data transformations while minimizing storage costs and build times.

​How View Materializations Work

​When to Use View Materializations

​Configuring View Materializations

​Model-Level Configuration

​Project-Level Configuration

​Performance Considerations

​Advantages and Limitations

​When to Consider Other Materializations

​Best Practices

How View Materializations Work

When to Use View Materializations

Configuring View Materializations

Model-Level Configuration

Project-Level Configuration

Performance Considerations

Advantages and Limitations

When to Consider Other Materializations

Best Practices