What is dbt, and who owns its upgrades before end of life?

dbt is the transformation layer of a data stack: your team writes SQL select statements, and dbt turns them into modular, tested models inside the warehouse. Its upgrades belong to the platform or data platform lead who runs dbt in production, with model fixes staying with the model authors. Name that person now, because dbt 1.11 reaches end of life on 2026-12-19.

Treat dbt upgrades as a platform engineering job with a data owner attached. The install, the CI job and the schedule sit on one side. The models that may need changes sit on the other. If two teams each assume the other has it, nobody has it.

A reading of the endoflife.date registry on 2026-11-03 shows three dbt release lines with end dates coming up. The nearest is 1.11, 46 days after that date. dbt’s own versions page lands one day earlier on each line, so plan to dbt’s date.

1.11 is the deadline. Choosing between 1.12 and 2.0 is about the size of the move, because they end 60 days apart.

What is dbt in data engineering?

dbt is the tool that transforms raw warehouse data into data products the rest of the company can use. It works alongside your ingestion and visualization tools, and the transformation runs directly in your cloud data platform.

The framework has two parts. The language is what your people write: SQL select statements, Jinja templating, YAML configs and tests. The engine compiles the project, executes the transformation graph and produces metadata.

There are also two generations. v1 is the original Python-based one, and it stays on the 1.x series. v2 is the Rust-based generation, uses the 2.x series, and is the default experience when you install dbt.

A new default install gets v2, so check what your CI job actually installs.

dbt brings version control, testing, CI/CD and documentation to analytics code. So it deserves the treatment of any other production dependency, with support windows and someone who keeps up with them.

What happens when a dbt version reaches end of life?

It stops receiving new patch releases. dbt’s v1 policy gets there in stages, and the stages matter more than the final date.

A minor version starts in active support, with bug fixes during its first few months. When a newer minor ships, the previous one moves to critical support for the rest of its one-year window. Patches then cover only critical security and installation fixes. When the window closes, the version is end of life.

There’s one more stage. dbt’s page describes deprecated versions as no longer maintained by dbt Labs and no longer supported in the dbt platform, and it lists v1.10 that way. A team still on v1.10 has a more urgent problem than this post’s deadline.

dbt’s page lists 1.11 in critical support, so teams on it already get a narrow set of fixes. After December 18, the line gets nothing new.

If an installation problem surfaces on self-hosted 1.11 in January, there’s no patch to plan on. The fix is an upgrade, done under pressure, on a schedule nobody chose.

255 days overstates how long 1.12 gets ordinary bug fixes. Its end date is 2027-07-16. But v1.13 is in beta and listed as coming soon. Under the policy above, 1.12 moves to critical support once a newer minor ships.

Who should own dbt upgrades?

One named person should own the date, and that person comes from the team that runs dbt in production. In a self-hosted setup, that’s the platform or data platform lead, because they control the install, the CI job and the runtime. On the dbt platform, it’s someone who holds the permissions over environments and jobs.

Model fixes stay with the people who wrote the models. The owner tracks which version runs where and decides when the move is finished. If the line between those teams is already fuzzy, this breakdown of platform engineering, DevOps and SRE is a useful place to settle it.

dbt Labs’ guide on leaving self-hosted dbt lists one telling reason a team might read it: the person who set up the deployment has left. That guide is selling the dbt platform, so discount it accordingly. The question is still worth asking about your own team.

Ask who gets the ticket when 1.11 stops getting patches. If you don’t get exactly one name, you have no owner.

The owner also carries a licensing question. v2 ships in two distributions. dbt recommends the full v2 install, and points organizations with a strict Apache 2.0 requirement to dbt OSS. If your company has that requirement, the owner should raise it before the v2 project starts. It’s much cheaper to learn this before the install than after it.

Does the dbt platform remove the upgrade problem?

Partly. Release tracks deliver minor version updates automatically, and dbt says platform users don’t need to manage versions themselves. If every environment is on a track, that chore is gone.

The rest stays with you. Jobs and environments are each configured to use a specific version, and a legacy v1 version can still be selected in the dropdown. So someone still has to check what each one is set to.

Moving to v2 is also still a project. dbt describes it as a multi-step process, and each task has its own required permissions. To use the upgrade assistant and other upgrade tools, you need the v1 Latest release track and a developer license. v2 is generally available for Snowflake, BigQuery, Redshift and Databricks projects, and in preview for other supported adapters on the platform. If the v2 Stable track doesn’t appear as an option, dbt tells you to ask your account team about eligibility.

Leaving self-hosted dbt is a separate decision, and I wouldn’t make it because of one deadline. dbt Labs argues that self-hosting hides its true cost in engineer hours and wasted compute. That’s the vendor’s claim, so put your own numbers next to it. The reasoning has the same shape as the build or buy question for an internal platform.

How do you plan a dbt upgrade before support ends?

Start with an inventory, move 1.11 first, and treat v2 as its own project.

The inventory is short. Run dbt --version everywhere dbt runs, including laptops, CI and your orchestrator. On the dbt platform, check each environment and each job. Write the version next to the name of the person responsible for that install.

Then deal with 1.11. I’d move to 1.12 before December 18, because dbt Labs calls v2 a ground-up rebuild, and that’s too big to combine with a short deadline. The exception is a project that’s already been tested on v2 with a generally available adapter. That project can go straight there.

Test in development first, which is also what dbt Labs recommends. On the platform, the Override dbt version setting only affects your own user account. One engineer can try the new version without touching colleagues. After that, upgrade the deployment environments and the default development environment. In a self-hosted setup, follow the same order with a branch in CI.

Then schedule v2. Start by April 2027, about 90 days before the end of 1.12. The platform has an upgrade assistant that steps you through preparing and upgrading your projects, and it has a Run once on dbt v2 job action. I’d use both before switching an environment, because I expect them to show problems early. Warn people ahead of the switch, because every user has to restart the IDE after the development environment moves to v2 Stable.

The move should pay off later. dbt says v2 minor versions are backwards compatible and won’t break project code that relies on documented functionality. So I expect staying current on v2 to cost less than this generation change. That’s a reading of the policy, and your own project will confirm it or not.

Last, have the owner choose the channel for local and CI installs. dbt marks latest as recommended for most users, while canary is still undergoing testing and dev may not have passed all tests. Keep production on latest.

What should you decide about dbt this quarter?

Decide who owns the date and which line each project moves to.

Anything older than 1.11 goes first. A project on 1.11 moves to 1.12 by December 18, unless its v2 testing is already done. A project on 1.12 has no emergency, but its owner should have April 2027 on the calendar. A project on 2.0 has the smallest job: stay on a stable channel and track Sept 13, 2027.

Block 30 minutes this week. Run dbt --version everywhere dbt runs, write each result next to a name, and put December 18 on that person’s calendar. If a row has no name, start there.

How the numbers were produced

• Type: dated registry reading.
• Source: https://endoflife.date/api/v1/products/dbt/.
• Read at: 2026-11-03T16:11:01-03:00.
• Computation: read https://endoflife.date/api/v1/products/dbt/ (mirror updated 2026-10-15T00:09:10+00:00), then days = end of life minus 2026-11-03 for every release line.

3 release lines of dbt have an end-of-life date within the window from 120 days before to 540 days after 2026-11-03; the nearest is 1.11 (46 days after the reading date)
dbt 1.11: end of life 2026-12-19, 46 days after the reading date; latest patch 1.11.16
dbt 1.12: end of life 2027-07-16, 255 days after the reading date; latest patch 1.12.6
dbt 2.0: end of life 2027-09-14, 315 days after the reading date; latest patch 2.0.8

Sources

• docs.getdbt.com, retrieved 2026-11-03 (sha256 f4b84a03d576).
• docs.getdbt.com, retrieved 2026-11-03 (sha256 177d71af51b3).
• docs.getdbt.com, retrieved 2026-11-03 (sha256 252e0f49d5c6).
• docs.getdbt.com, retrieved 2026-11-03 (sha256 e27d50205f87).

Work with Clouditive

Clouditive places nearshore engineers with US teams. See how to hire them.