With the recent release of the DBT v2 beta, the data transformation tool has undergone its biggest update to date. Given the significant nature of this change, it’s worth taking a closer look at what it entails and what has been rethought.
Key new features in DBT 2.0
Below, we’ll take a look at the key new features in the latest version of DBT, which has been available for general access since September 2026.
The first of these is that the tool now comes in two distributions. Thus, dot v2 will have two packages: dbt-core-v2 and dbt (formerly dbt fusion). Both will be available for free, but paid features are included in DBT. Furthermore, dbt-core v2 contains only open-source code and no paid features, while dbt contains proprietary code distributed as a binary.
Another innovation in this new version is the change in the engine. The new foundation of dbt-core is in Rust, not pure Python as in v1. This is because the dbt fusion engine is now used in dbt-core v2, enabling faster execution speeds.
Additionally, there are new artifacts based on Parquet. Previously, large DBT projects faced the issue that certain files were difficult to modify and read because they were large JSON files. Now, they are stored in Parquet, enabling fast reading and indexing.
Additionally, DBT now continues compiling even when errors occur. Previously, if a node could not be compiled due to an error, DBT would stop immediately. Now, it will not compile any downstream nodes, but it will continue compiling other nodes if they exist.
Greater rigor in specification and parsing
A significant portion of the changes in dbt v2 involve greater rigor in specification and parsing. Previously, DBT would often fail silently, resolving conflicts internally rather than making them explicit, and waiting until compilation to detect errors. The move to v2 aims to avoid this process, and to that end, the features we’ll discuss below have been introduced.
Strict language specification
Previously, DBT would fail silently when it encountered incorrectly defined language, such as “descriptin” instead of “description.” This is no longer an issue, thereby preventing silent bugs.
Parsing-time errors
Instead of failing at compile time, when it detects nonexistent macros or adapters, undefined tests, or undefined variables, it will throw an error without waiting for the compilation to complete.
Package conflicts
In the previous version, if a dependency conflict existed, it was silently resolved in favor of the root package; now, it will generate an error.
Duplicate documentation
Version 1 allowed the creation of duplicate documentation blocks. However, in version 2, names are evaluated more strictly to prevent ambiguity. Thus, if a conflict occurs, it will result in an error.
Top-level keys
The presence of unexpected top-level keys in a YAML file will now cause an error. If you want to use them to define a reusable block, you must do so under the :anchors key.
Algebraic operations in Jinja
It is no longer possible to include algebraic functions within a Jinja macro, as was previously the case.
Changes to dbt v2 parameters and modifiers
A significant number of CLI flags have been deprecated and will not be used in v2; the following are particularly important:
- -m / –model / –models: Use
–selector-sinstead. - –resource-type / –exclude-resource-type: Use
–resource-typesorexclude-resource-typesinstead.
Using either of the two flags listed above will cause the CLI to fail. Other deprecated flags will simply be ignored and will not cause errors.
Due to the significant changes involved in the update from v1.12.0 to v2, two tools have been added to facilitate the transition:
- Test parser. You can use the
--use-v2-parserflag to force the use of the v2 parser. This will allow you to test whether any changes need to be made. - Autofix. There is also a published tool that will facilitate the transition:
dbt-autofix. Its purpose is to read the project configuration and update it for version v2.
Conclusion
DBT v2 represents a significant improvement in execution and compilation times. Furthermore, thanks to the change in the engine and the shift from pure Python to Rust—which takes advantage of this feature—greater rigor is introduced to prevent common issues that previously caused silent bugs (where, due to a poor definition, no error is generated and the behavior deviates from what is expected).
With these new changes, DBT has become a more maintainable and efficient tool. It also makes it a very good choice for any SQL-based data processing task.
If you found this article interesting, we encourage you to visit the Data Engineering category to see other posts similar to this one and to share it on networks. See you soon!
