Skip to main content

Upgrading to v1.12

Beta coming soon

dbt Core v1.12 is not yet available in beta. We will update this guide when it becomes available.

Resources​

What to know before upgrading​

dbt Labs is committed to providing backward compatibility for all versions 1.x. Any behavior changes will be accompanied by a behavior change flag to provide a migration window for existing projects. If you encounter an error upon upgrading, please let us know by opening an issue.

dbt provides the functionality from new versions of dbt Core via release tracks with automatic upgrades. If you have selected the Latest release track in dbt, you already have access to all the features, fixes, and other functionality included in the latest dbt Core version! If you have selected the Compatible release track, you will have access to the next monthly Compatible release after the dbt Core v1.12 final release.

We continue to recommend explicitly installing both dbt-core and dbt-<youradapter>. This may become required for a future version of dbt. For example:

python3 -m pip install dbt-core dbt-snowflake

New and changed features and functionality​

Compiled SQL for snapshots Beta​

dbt compile writes compiled SQL for snapshots to target/compiled/, consistent with models, tests, analyses, and functions. Each snapshot gets its own output file, named from the snapshot identifier, so multiple snapshot blocks in the same source file do not share one compiled path.

For more information, refer to About dbt compile.

Support for vars.yml Beta​

You can use the vars.yml file, located at the project root, to define project variables. This keeps variable definitions in one place and helps simplify dbt_project.yml. Variables defined in vars.yml are parsed before dbt_project.yml, so you can reference them in dbt_project.yml using {{ var('...') }}. You can continue to define variables in dbt_project.yml as before, but you cannot define variables in both files. For details and precedence, refer to Project variables.

Managing changes to legacy behaviors​

dbt Core v1.12 introduces new flags for managing changes to legacy behaviors. You may opt into recently introduced changes (disabled by default), or opt out of mature changes (enabled by default), by setting True / False values, respectively, for flags in dbt_project.yml.

You can read more about each of these behavior changes in the following links:

Adapter-specific features and functionalities​

Snowflake​

BigQuery​

  • Added the bigquery_reject_wildcard_metadata_source_freshness flag. When you set this flag to True, dbt raises a DbtRuntimeError if you run metadata-based source freshness checks with wildcard table identifiers (for example, events_*), preventing incorrect freshness results.
  • You can configure BigQuery job link logging with job_link_info_level_log. By default, dbt logs job links at the debug level. To log job links at the info level, set job_link_info_level_log: true in your BigQuery profile. This makes job links visible in dbt logs for easier access to the BigQuery console. For more information, see BigQuery setup.
  • You can set job_execution_timeout_seconds per model, snapshot, seed, or test, in addition to the profile-level configuration. The per-resource value takes precedence over the default value set in the profile level. For more information, refer to BigQuery setup.

Redshift​

  • Added support for the query_group session parameter, allowing dbt to tag queries for Redshift Workload Manager routing and query logging. When configured in a profile, dbt sets query_group when opening a connection and the value applies for the duration of that session. You can also configure query_group at the model level to temporarily override the default value for a specific model, and dbt reverts the value at the end of model materialization. For more information, see Redshift configurations.

Quick hits​

Coming soon

Was this page helpful?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

0
Loading