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