Skip to main content

Model configurations

▶Changelog

Available configurations​

Model-specific configurations​

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

General configurations​

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

Warehouse-specific 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