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

#350: Bolt - Template fixes pt 1

Change request updated