Grace Goheen

Today, we published the first alpha release of dbt Core version 2.0, raising the baseline for what dbt users can expect from their transformation tool. As always, dbt Core's code is completely open source under the Apache 2.0 license. What makes this release significant is that dbt Core v2.0 is now built on the same foundations as the dbt Fusion engine – we've open-sourced a lot of Fusion code for the first time.

The launch of dbt Core v2.0 comes with key feature developments:

• Significant parse time improvements, especially on the largest dbt projects
• A tightly-defined language spec which makes it impossible to accidentally configure a desciptin instead of a description, and gives anyone integrating with the dbt ecosystem (including dbt's own development team!) a stable interface to build against.
• New Parquet artifacts as a high-performance alternative to large JSON files that can be directly queried through DuckDB or your agent of choice
• A completely revamped local documentation experience, powered by those new artifacts and capable of scaling to projects of arbitrary size.
• A more streamlined way to build new adapters, powered by ADBC and the Arrow ecosystem
• A simplified installation process that removes the need to fight with Python's virtual environments

Why we built this: A brief history of the dbt Labs Professional Services team​

If you attended Coalesce 2022, you’ll know that the secret is out — the dbt Labs Professional Services team is not just a group of experienced data consultants; we’re also an intergalactic group of aliens traveling the Milky Way on a mission to enable analytics engineers to successfully adopt and manage dbt throughout the galaxy.

Why do people cherry pick into upper branches?​

The simplest branching strategy for making code changes to your dbt project repository is to have a single main branch with your production-level code. To update the main branch, a developer will:

1. Create a new feature branch directly from the main branch
2. Make changes on said feature branch
3. Test locally
4. When ready, open a pull request to merge their changes back into the main branch

If you are just getting started in dbt and deciding which branching strategy to use, this approach–often referred to as “continuous deployment” or “direct promotion”–is the way to go. It provides many benefits including:

• Fast promotion process to get new changes into production
• Simple branching strategy to manage

The main risk, however, is that your main branch can become susceptible to bugs that slip through the pull request approval process. In order to have more intensive testing and QA before merging code changes into production, some organizations may decide to create one or more branches between the feature branches and main.

There are many reasons you, as an analytics engineer, may want to capture the complete version history of data:

• You’re in an industry with a very high standard for data governance
• You need to track big OKRs over time to report back to your stakeholders
• You want to build a window to view history with both forward and backward compatibility

These are often high-stakes situations! So accuracy in tracking changes in your data is key.