Impact Score: 5/10
dbt Core: dbt 0.5.3
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.3. Source highlight: Fixes regressions introduced in 0.5.1 and 0.5.2.
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)
Bugfix release.
Fixes regressions introduced in 0.5.1 and 0.5.2.
### Fixed 0.5.1 regressions
Incremental models were broken by the new column expansion feature. Column expansion is implemented as
``` sql
alter table ... add column tmp_col varchar({new_size});
update ... set tmp_col = existing_col
alter table ... drop column existing_col
alter table ... rename tmp_col to existing_col
```
This has the side-effect of moving the `existing_col` to the "end" of the table. When an incremental model tries to
``` sql
insert into {table} (
select * from tmp_table
)
```
suddenly the columns in `{table}` are incongruent with the columns in `tmp_table`. This insert subsequently fails.
The fix for this issue is twofold:
1. If the incremental model table DOES NOT already exist, avoid inserts altogether. Instead, run a `create table as (...)` statement
2. If the incremental model table DOES already exist, query for the columns in the existing table and use those to build the insert statement, eg:
``` sql
insert into "dbt_dbanin"."sessions" ("session_end_tstamp", "session_start_tstamp", ...)
(
select "session_end_tstamp", "session_start_tstamp", ...
from "sessions__dbt_incremental_tmp"
);
```
In this way, the source and destination columns are guaranteed to be in the same order!
### Fixed 0.5.2 regressions
We attempted to refactor the way profiles work in dbt. Previously, a default `user` profile was loaded, and the profiles specified in `dbt_project.yml` or on the command line (`with --profile`) would be applied on top of the `user` config. This implementation is [some of the earliest code](https://github.com/analyst-collective/dbt/commit/430d12ad781a48af6a754442693834efdf98ffb1) that was committed to dbt.
As `dbt` has grown, we found this implementation to be a little unwieldy and hard to maintain. The 0.5.2 release made it so that only one profile could be loaded at a time. This profile needed to be specified in either `dbt_project.yml` or on the command line with `--profile`. A bug was errantly introduced during this change which broke the handling of dependency projects.
### The future
The additions of automated testing and a more comprehensive manual testing process will go a long way to ensuring the future stability of dbt. We're going to get started on these tasks soon, and you can follow our progress here: https://github.com/analyst-collective/dbt/milestone/16 .
As always, feel free to [reach out to us on Slack](http://ac-slackin.herokuapp.com/) with any questions or concerns: