Model configurations

▶Changelog

Related documentation

• Models
• run command

Available configurations

Model-specific configurations

Project file

dbt_project.yml

models:  <resource-path>:    +materialized: <materialization_name>    +sql_header: <string>

Property file

models/properties.yml

version: 2
models:  - name: [<model-name>]    config:      materialized: <materialization_name>      sql_header: <string>

Config block

models/<model_name>.sql

{{ config(    materialized="<materialization_name>",    sql_header="<string>") }}

General configurations

Project file

dbt_project.yml

models:  <resource-path>:    +enabled: true | false    +tags: <string> | [<string>]    +pre-hook: <sql-statement> | [<sql-statement>]    +post-hook: <sql-statement> | [<sql-statement>]    +database: <string>    +schema: <string>    +alias: <string>    +persist_docs: <dict>    +full_refresh: <boolean>    +meta: {<dictionary>}

Property file

models/properties.yml

version: 2
models:  - name: [<model-name>]    config:      enabled: true | false      tags: <string> | [<string>]      pre-hook: <sql-statement> | [<sql-statement>]      post-hook: <sql-statement> | [<sql-statement>]      database: <string>      schema: <string>      alias: <string>      persist_docs: <dict>      full_refresh: <boolean>      meta: {<dictionary>}

Config block

models/<model_name>.sql

{{ config(    enabled=true | false,    tags="<string>" | ["<string>"],    pre_hook="<sql-statement>" | ["<sql-statement>"],    post_hook="<sql-statement>" | ["<sql-statement>"],    database="<string>",    schema="<string>",    alias="<string>",    persist_docs={<dict>},    meta={<dict>}) }}

Warehouse-specific configurations

• BigQuery configurations
• Redshift configurations
• Snowflake configurations
• Spark configurations

Configuring models

Models can be configured in one of three ways:

1. Using a config() Jinja macro within a model
2. Using a config resource property in a .yml file
3. From the dbt_project.yml file, under the models: key.

Model configurations are applied hierarchically. The most-specific config always "wins": In the project file, configurations applied to a marketing subdirectory will take precedence over configurations applied to the entire jaffle_shop project. To apply a configuration to a model, or directory of models, define the resource path as nested dictionary keys.

Example

Configuring directories of models in dbt_project.yml

To configure models in your dbt_project.yml file, use the models: configuration option. Be sure to namespace your configurations to your project (shown below):

dbt_project.yml

name: dbt_labs
models:  # Be sure to namespace your model configs to your project name  dbt_labs:
    # This configures models found in models/events/    events:      +enabled: true      +materialized: view
      # This configures models found in models/events/base      # These models will be ephemeral, as the config above is overridden      base:        +materialized: ephemeral
      ...

Apply configurations to one model only

Some types of configurations are specific to a particular model. In these cases, placing configurations in the dbt_project.yml file can be unwieldy. Instead, you can specify these configurations at the top of a model .sql file, or in its individual yaml properties.

models/events/base/base_events.sql

{{  config(    materialized = "table",    sort = 'event_time',    dist = 'event_id'  )}}

select * from ...

models/events/base/properties.yml

version: 2
models:  - name: base_events    config:      materialized: table      sort: event_time      dist: event_id