dbt Fusion in practice: why we were sceptical at first and have now switched

In February 2026, our internal tech radar had one blunt line on it: "dbt Fusion is not production-ready." At the end of September we switched our dbt template to Fusion anyway. The template is what we set up every new data project from (folder structure, configuration, packages, style guide), so every new project at Gemma now starts on Fusion.

Are we contradicting ourselves? Not quite. Both decisions had good reasons at the time. This piece covers what Fusion actually does better day to day, why our first test went wrong, what a migration from dbt Core costs, and when you're better off waiting.

What is dbt Fusion?

dbt Fusion is the new engine behind dbt. dbt Labs rewrote it from scratch, in Rust instead of Python, and now calls it "dbt v2". If you install dbt fresh today, this is the version you get (dbt Docs).

The big difference is under the hood. dbt Core renders your Jinja to SQL and sends it to the warehouse. Whether the SQL is correct, you only find out when the warehouse sends back an error. Fusion understands SQL. It knows columns, types and dependencies before anything runs.

Handy for the switch: to try Fusion out, we install it system-wide as a standalone program, not in the project's Python environment. That way it sits next to an existing dbt Core installation without getting in its way. For us, dbtf always calls Fusion, and dbt in the active venv still calls dbt Core. You can compare both on the same project without breaking anything. Once a project has switched, we pin the Fusion version in the project itself (more on that in the migration section).

What Fusion improves day to day

What we notice most is faster feedback while writing, more than raw speed. Four things stand out:

1. Errors before anything runs. The official dbt extension for VS Code flags bad SQL and broken Jinja right in the editor. A mistyped column name shows up as you type, not after a three-minute build. The extension needs Fusion and is free. Some features need a dbt account, also free.
2. Preview and lineage in the editor. You can preview models and individual CTEs without leaving the editor, and see lineage down to column level. We switch to the warehouse for quick sanity checks less often.
3. Fast parsing. At launch, dbt Labs advertised up to 30 times faster parsing. To be honest, compilation was rarely our bottleneck. On large projects with many models you do feel it, though, especially in CI.
4. Fast feedback without an editor, too. More and more work on dbt projects happens in the terminal, often with AI agents like Claude Code. Fusion's static analysis also runs on dbtf compile, so an agent learns within seconds that its SQL doesn't fit, without a single query to the warehouse. One catch: in the default baseline mode, the findings are only warnings. Fusion only detects type errors in strict mode.

Old projects have a catch of their own: the error highlighting follows the current syntax. Open a repo on an old dbt version and you'll be buried in warnings at first. That's annoying, but it's also a pretty clear hint that an upgrade is due.

Our first test: faster and slower at the same time

In February 2026 we tried Fusion on two projects. The results contradicted each other:

Project	dbt Core	dbt Fusion
jaffle_shop (demo project by dbt Labs)	approx. 25 s	approx. 10 s
Our internal project on Snowflake	approx. 20 s	approx. 120 s

On the demo project, Fusion was more than twice as fast. On our own project, the build took six times as long.

Our code wasn't the problem. At the time, Fusion ignored the threads setting for Snowflake as part of its own performance optimisation, so it fired off more queries at once than we had configured. Our small XS warehouse couldn't keep up and the queries piled up. More parallelism made everything slower.

That's where our "not production-ready" verdict came from. The more useful lesson was a different one: benchmarks from blog posts say little about your project (this one included).

Why Fusion became our standard anyway

A lot changed between February and September. In mid-September, dbt Labs officially released Fusion as dbt v2.0.0, and stable releases have replaced the previews since then.

The threads problem from our test is solved, too. We had reported it to dbt Labs in February, and over the following months plenty of other users turned up with the same issue, on BigQuery and Redshift as well. Since May 2026, Fusion treats threads as an upper limit (dbt Docs), so on a small warehouse you can cap parallelism again. In November we reran our test with the same settings. This time Fusion was slightly faster than dbt Core: around 18 seconds instead of 22.

And the editor feedback pays off every day, most of all during onboarding. Someone new to the team sees errors right away instead of in a failed build.

Our new internal data project runs entirely on Fusion, including the dbt jobs in our Airflow. We work with the same setup we build for our clients.

Migrating from dbt Core to Fusion: effort and pitfalls

If your project already runs on current dbt Core without deprecation warnings, the switch is about as much work as a normal version upgrade. That's also the prerequisite dbt Labs names. Fusion is largely backwards compatible. Older projects first need the work any major upgrade would bring. Our template jumped straight from 1.6 to Fusion, and these were the steps:

1. Adjust the version constraint. The dbt_project.yml now says require-dbt-version: ['>=2.0.0-preview', '<3.0.0'].
2. Move test parameters. Parameters of generic tests go under arguments:. We set the flag require_generic_test_arguments_property: true so old notation shows up immediately.
3. Move tags and meta under config:. Another pure syntax change, but it touches almost every YAML file.
4. Update packages. dbt deps tells you which packages aren't compatible. For us that was dbt_utils (now 1.4.1) and dbt_snowflake_monitoring (now 5.x).
5. Check sql_header. Fusion stops parsing if +sql_header is set on snapshots, seeds or analyses. We removed it there. For models and tests, we still set the time zone via +sql_header in the dbt_project.yml.
6. Pin the version in the project. For testing, the binary (curl, brew or winget) is enough. In a project that has switched, we install Fusion with pip or uv into the project's Python environment, with a fixed version, since the dbt package now installs dbt v2. The version then lives in the repo, and every change to it goes through a pull request. dbt Core and Fusion can't share a Python environment, though, so for a side-by-side comparison the binary is still the simpler route.

Two things we only learned later:

• Pin the same version everywhere. Fusion moves fast. At one client, the Fusion 2.0 release broke the CI build. So we pin the version, and identically: locally, in CI and in the orchestration image (Airflow, in our case). The easiest way is a lockfile in the repo that all three install from.
• SQLFluff doesn't fit Fusion directly. If your team leans heavily on SQLFluff, plan time for this. dbt Labs describes several approaches in the documentation, but none of them is plug-and-play.

Everything else stayed the same: structure, folders, conventions. Most of a project you won't have to touch.

When you shouldn't switch (yet)

Fusion is our new standard, but it isn't the right call for every project right now. In these cases we'd wait:

• Your warehouse isn't supported. Fusion runs on Snowflake, BigQuery, Databricks and Redshift, plus DuckDB locally. ClickHouse and Spark are still in beta. Postgres and Microsoft Fabric are missing for now (as of November 2026).
• Your tools read dbt Core's logs. Fusion writes different logs. Monitoring or scripts that expect exactly that format will need adapting.
• You need dbt platform features that v2 doesn't support yet, for example model-level notifications.

Even if your project fits: test on the side first. Since Fusion runs alongside dbt Core, dbtf parse shows you, at no risk, how much migration work lies ahead before you touch your CI.

FAQ about dbt Fusion

Is dbt Fusion the same as dbt 2.0? Yes. Fusion is the engine, and dbt Labs now calls the version dbt v2. dbt Core (v1) is still maintained in parallel.

Is dbt Fusion free? The engine and the VS Code extension are free to use. Some features need a free dbt account. The standard distribution of dbt v2 is proprietary, though, and licensed by dbt Labs. If you need open source, dbt-oss is an Apache 2.0 variant on the same Rust engine, with fewer features. dbt Core (v1) also stays Apache 2.0.

Can I use dbt Core and Fusion side by side? Yes. Install Fusion system-wide as a binary and dbt Core as usual in your Python environment. An alias like dbtf lets you call Fusion explicitly.

Is Fusion always faster than dbt Core? No. Parsing is much faster, but how long a build runs also depends on your warehouse. In our first test in February 2026, Fusion was six times slower on a small Snowflake warehouse because it ignored the threads setting. That's been fixed since May 2026. Set threads to match your warehouse and compare for yourself.

Is Fusion worth it if I work with AI agents? Yes, maybe even more than in the editor. An agent like Claude Code checks its SQL with dbtf compile in seconds, without querying the warehouse. And because an agent often compiles dozens of times per task, fast parsing matters here too. In the default baseline mode, the findings are only warnings, and an agent can easily miss them. With static_analysis: strict, Fusion checks more thoroughly, data types included.

How much work is the migration? If your project runs on current dbt Core without deprecation warnings, about as much as a normal version upgrade. Most changes are YAML syntax and package versions. dbt Labs also offers agent skills that automate part of the migration.

Conclusion: test, measure, then switch

Our first impression of Fusion was bad, and back then it was justified. Seven months later, Fusion is our standard for new projects. Benchmarks weren't what tipped it. The daily work did, in the editor and in the terminal, along with what we saw in real projects.

If you're thinking about switching, start small. Install Fusion next to dbt Core and run dbtf parse. A few minutes later you'll know how far your project is from Fusion. dbt-autofix fixes a lot of that automatically, and the rest is usually the pitfalls above.

Want to migrate an existing dbt project, or set up a new data platform on Fusion from day one? Talk to us. We've been down this road several times.