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.
โก 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
```