Model Materializations

Overview

dbt™️ employs various strategies, known as materializations, to persist models within a data warehouse. The platform offers five built-in materialization types:

Additionally, dbt™️ allows for the configuration of custom materializations, providing a robust method to extend the platform's capabilities to address specific requirements.

Setting Up Materializations

By default, dbt™️ materializes models as "views". However, you can specify a different materialization type by utilizing the materialized configuration parameter.

The following section demonstrates how to implement this configuration.

dbt_project.yml
# The following dbt_project.yml configures a project that looks like this:
# .
# └── models
#     ├── finance
#     │   ├── revenue.sql
#     │   └── invoices.sql
#     └── operations
#         ├── stg_shipping.sql
#         └── stg_deliveries.sql

name: my_project
version: 1.0.0
config-version: 2

models:
  my_project:
    finance:
      # materialize all models in models/finance as tables
      +materialized: table
    operations:
      # this is redundant, and does not need to be set
      +materialized: view

In-File Materialization Configuration

Materialization settings can be specified directly within the SQL files of individual models. This will overrride the the value set in the dbt_project.yml file.

{{ config(materialized='table', sort='timestamp', dist='user_id') }}

select *
from ...

This method of configuration allows for greater flexibility and precision in optimizing each model's performance based on the specific requirements of your data warehouse platform.

Last updated

Was this helpful?

#350: Bolt - Template fixes pt 1

Change request updated