# 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:

1. Creates or replaces the view definition using your model's SQL
2. Stores the query definition, not the actual data
3. 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:

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

{% hint style="info" %}
Views are ideal when you need real-time data or when build time is more important than query performance.
{% endhint %}

***

### 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

```sql
-- 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

```yaml
# 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 | <p>• Secure views option<br>• Materialized views available<br>• Query optimization</p> |
| BigQuery  | <p>• Authorized views<br>• Materialized views<br>• Query caching</p>                   |
| Redshift  | <p>• Late binding views<br>• Materialized views<br>• Query planning</p>                |

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

```sql
{{
    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

1. **Default to Views**: Start with views for most models and change only when needed
2. **Staging Models**: Keep staging models as views for flexibility
3. **Query Optimization**: Write efficient SQL to reduce runtime overhead
4. **Monitor Performance**: Watch for slow-running views and consider materializing as tables
5. **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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.paradime.io/app-help/concepts/dbt-fundamentals/model-materializations/view-materialization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.