New code, new license: Understanding the new license for the dbt Fusion engine

Hi all! You’ve likely read about our massive launch today. It is not an exaggeration to say that this is the single biggest launch event for us in many years. The dbt Fusion engine. dbt Canvas. Cost Management. And more.

There’s one announcement that I want to zoom in on in this post: licensing for the dbt Fusion engine. This is something that I care a lot about and have thought a lot about, and I want to share that thinking, zero filter, with you.

Here are the main three points to know at the outset:

1. The license for dbt Core is not changing. dbt Core remains Apache 2 OSS and we will continue to support it indefinitely.
2. Today, we introduced the brand new dbt Fusion engine to power the next era of analytics engineering. The dbt Fusion engine contains a mixture of source-available, proprietary, and open source code. The source-available components of the Fusion engine will be available under the Elastic Version 2 (ELv2) License.
3. At GA, the source available and open source components of the dbt Fusion engine will support all features in dbt Core and more. Fusion will be a strictly better offering whether you’re paying us or not.

You can read the Licensing FAQ for full details. The upshot is: If you're a data team that uses dbt Core today, nothing about the Fusion engine’s new license (ELv2) prevents you from upgrading to Fusion and using it just like you use Core today. You don’t need to pay us anything, give us your contact info, or speak with anyone. You run it locally, and you can see (and contribute to!) the source code.

You cannot use it to directly compete with dbt Labs by hosting a managed service powered by the dbt Fusion engine.

Let’s dive in.

The biggest update: dbt Core and the dbt Fusion engine

In January, we announced that we had acquired a company called SDF Labs. SDF had, over the course of multiple years in stealth, built a brand new engine for data transformation. It was written in Rust, blazing fast, and had meaningful new features, all stemming from its ability to both parse and compile SQL in many dialects.

Since then, we have been sprinting to integrate SDF’s technology into the overall dbt experience. The main outcome of this is the launch of Fusion, a brand new engine for dbt, rewritten from the ground up incorporating the best elements of dbt and SDF into a single engine. New code, new product, more functionality. The authoring specification itself is shared—code that is working in dbt Core will also work in Fusion, with a few exceptions. But under the hood - other than the adapter macros and materializations - not a single line of code between Fusion and dbt Core is shared!

Upon acquisition, SDF’s source code was proprietary, and the original plan was actually to stick to that strategy. As you would expect, we had to pay real $$$ for the acquisition, and, given that, open sourcing all the IP seemed hard to justify.

But, having some time to process, we wanted to see if we could do better. Better for the dbt Community and better for dbt Labs. And I think the approach we’ve come to is much better for both.

Here are the specifics:

1. Separate the code Separate dbt Core and the dbt Fusion engine. They are two totally separate engines, with zero shared tech. Reflect that in the repository structure.
2. Continue to support dbt Core as Apache 2.0 Continue to support dbt Core indefinitely. Bug fixes, security patches, maintaining compatibility with data platforms, etc. Keep the Apache 2.0 license on this repo. If you are currently using dbt Core and for some reason prefer not to migrate to Fusion, nothing is being taken away from you. If you are a vendor using dbt Core to compete directly with dbt Labs, your ability to do that has not changed.
3. Apply a new license to Fusion License the Fusion code base under ELv2 to protect dbt Labs’ commercial interests but still maximizes users’ ability to view source code, contribute, locally install, use, and productionize an exclusively-better dbt experience.

Ultimately, Fusion is not only significantly better for the things that users have historically come to expect from dbt—data modeling and transformation—it also presents unique opportunities to build brand-new products. We think the entire dbt Community should use it. The way we’ve licensed it enables exactly that—there are no limitations on what users of Fusion can do with the code and its binaries as long as they comply with the three rules of ELv2:

• You may not provide the products to others as a managed service
• You may not circumvent the license key functionality or remove/obscure features protected by license keys
• You may not remove or obscure any licensing, copyright, or other notices

The ELv2 license does prevent other companies from using code from Fusion to directly compete with dbt Labs. Our goal is to build a long-term sustainable business, and this IP is an important part of our ability to do so.

Our choice was between making this new code proprietary and making it more open. We chose to make it more open.

Net new Apache 2 OSS

While Fusion will be released under the ELv2 license, we are continuing to contribute significant net new code in Apache 2.0-licensed open source. As a part of this launch, we are committing to contribute three new code bases licensed under Apache 2.0: Our brand new dbt Fusion adapters, all based on the Apache 2 Arrow Database Connector (ADBC) framework. We're all in on Arrow and are not only open sourcing these adapters, but dbt Labs team members are also frequent contributors to Arrow and ADBC.

• The ANTLR grammars that power multi-dialect SQL parsing, the result of thousands of hours of analysis across millions of SQL queries.
• A Rust-based implementation of Jinja called dbt-jinja, an essential component for being able to parse dbt projects without a Python interpreter.

We are making these libraries Apache 2 OSS because we believe there is significant Community value to build on top of these. Adapters, grammars, and the new faster standard for parsing dbt Jinja in Rust are foundational pieces of technology, and we hope the entire community finds them as useful as we do.

We’ll have more to say about this code in the coming weeks.

Why now? What changed?

While we are not changing the license of any existing code, I do want to acknowledge that this is an evolution of our open source strategy and I owe you an explanation.

dbt Core was originally built by data practitioners, for data practitioners. There’s a reason it caught fire: the workflow it enabled resonated deeply with the folks doing data work every day. And the Apache 2 license made it easy to adopt, and to become a standard, back when dbt Labs was half a dozen people and a viewpoint.

But dbt Core was built in 2016 and could never have imagined the needs of 2025. Translating between SQL dialects with complete fidelity. Local execution. Compilation times that are suitable for conversational AI interfaces. And much more. These needs just weren’t present in 2016, and they aren’t things that the original codebase can be extended to handle.

I am incredibly proud of what we all, collectively, have accomplished with dbt Core: elevating the careers of a million analytics engineers, bringing software engineering best practices to data, and building (IMHO) the most inclusive, magical community in data.

But one of the most challenging things in life is when you realize “what got us here won’t get us there.” Those moments show up in my personal and professional life and every single time they are hard and uncomfortable. Over my 44 years I’ve learned to lean into those moments and embrace the future—despite the challenges it often brings!—rather than getting anchored in the past.

Fusion is the future of the dbt engine. And Fusion is industrial-grade. It was built by some of the most talented software engineers in all of data.

And with industrial-grade quality comes industrial-grade investment. We need to build the business on top of this technology that it deserves, so that we can continue investing in it for many years to come.

Choosing the Elastic License was our best answer to the question: “How do we give the entire dbt Community an exclusively-better dbt experience while preserving space for ourselves to build a business around it?”

I continue to be a believer in Open Source, but I am realistic about the resources required to fund it. This is my best answer on how to balance both.

If you’re a longtime dbt user and want to chat about this, ping me on dbt Slack—I’m @tristan. Or ask questions in #dbt-fusion-engine.

I could not be more excited for the next decade of dbt, now powered by Fusion.