dbt Core v0.5.0stable Released Sep 28, 2016
Impact Score: 5/10

dbt Core: dbt version 0.5.0

Source available โ€” automated, not human-reviewed

Component: dbt-core ยท Channel: stable. Automated analysis, not a compatibility certification. How this works.

Analysis updated: 2026-11-01.

Compatibility not verified โ€” check source notes
๐Ÿ“„ .MD
โšก Executive Summary (TL;DR)

dbt Core v0.5.0. Source highlight: use a temp table when executing incremental models

Who Does This Impact? (Role-Based Analysis)

๐Ÿ’ป Software Engineers & Devs

Check the source notes against the package and APIs you use before upgrading.

๐Ÿ“Š Product & Engineering Leads

Use the documented changes to assess relevance to your product; release frequency alone is not a quality measure.

โš™๏ธ DevOps & Security

Verify the target version, runtime requirements and rollback procedure in the official documentation.

๐Ÿ“„ View Raw Release Notes (Original Developer Log)
### 0. tl;dr - use a temp table when executing incremental models - arbitrary configuration (using config variables) - specify branches for dependencies - more & better docs ### 1. new incremental model generation https://github.com/analyst-collective/dbt/issues/138 In previous versions of dbt, an edge case existed which caused the `sql_where` query to select different rows in the `delete` and `insert` steps. As a result, it was possible to construct incremental models which would insert duplicate records into the specified table. With this release, DBT uses a temp table which will 1) circumvent this issue and 2) improve query performance. For more information, check out the GitHub issue: https://github.com/analyst-collective/dbt/issues/138 ### 2. Arbitrary configuration https://github.com/analyst-collective/dbt/issues/146 Configuration in dbt is incredibly powerful: it is what allows models to change their behavior without changing their code. Previously, all configuration was done using built-in parameters, but that actually limits the user in the power of configuration. With this release, you can inject variables from `dbt_project.yml` into your top-level and dependency models. In practice, variables work like this: ``` yml # dbt_project.yml models: my_project: vars: exclude_ip: '192.168.1.1' ``` ``` sql -- filtered_events.sql -- source code select * from public.events where ip_address != '{{ var("exclude_ip") }}' -- compiles to select * from public.events where ip_address != '192.168.1.1' ``` The `vars` parameter in `dbt_project.yml` is compiled, so you can use jinja templating there as well! The primary use case for this is specifying "input" models to a dependency. Previously, dependencies used `ref(...)` to select from a project's base models. That interface was brittle, and the idea that dependency code had unbridled access to all of your top-level models made us a little uneasy. As of this release, we're deprecating the ability for dependencies to `ref(...)` top-level models. Instead, the recommended way for this to work is with vars! An example: ``` sql -- dbt_modules/snowplow/models/events.sql select * from {{ var('snowplow_events_table') }} ``` and ``` yml models: Snowplow: vars: snowplow_events_table: "{{ ref('base_events') }}" ``` This effectively mirrors the previous behavior, but it much more explicit about what's happening under the hood! ### 3. specify a dependency branch https://github.com/analyst-collective/dbt/pull/165 With this release, you can point DBT to a specific branch of a dependency repo. The syntax looks like this: ``` repositories: - https://github.com/analyst-collective/dbt-audit.git@development # use the "development" branch ``` ### 4. More & Better Docs! Check em out! And let us know if there's anything you think we can improve upon! ### Upgrading To upgrade to version 0.5.0 of dbt, run: ``` bash pip install --upgrade dbt ```