What we announced at Snowflake Summit and why it matters

We showed up at Snowflake Summit differently this year. In case you missed it: Fivetran and dbt Labs are now a single company, with a shared vision of building a foundation for trusted agents using open data infrastructure principles.

There's a lot to cover among all the announcements, so let's get into it.

Fivetran and dbt Labs have merged

If you've worked in data for the last decade, you know both names. Fivetran is the standard for getting data into your warehouse reliably and automatically, with connectors for virtually everything. dbt is the standard for data transformation. For years, teams have run Fivetran and dbt together. The combination was already the backbone of the modern data stack for thousands of organizations.

What changes now is that the Fivetran and dbt teams are working toward the same thing: a data foundation that’s open, portable, and ready for what agents need.

Customers of both Fivetran and dbt are already leading successful, trusted AI and agent initiatives, backed by our products. The value of this combined approach was emphasized by Piyush Bhargava, Sr. Director Global Data & Analytics at DocuSign: "AI and agents are only as strong as the data behind them. By investing in Fivetran and dbt, we've built the reusable, trusted data assets that are central to how we scale AI and drive innovation."

You can read a lot more about the merger thesis, dbt's continued commitment to open source, and what's next in Tristan's blog.

dbt Core v2.0: The open-source foundation, rebuilt on Fusion

dbt Core started in 2016 as a way for data practitioners to work like software engineers with modular SQL, version control, testing, and documentation in an open-source framework. It quickly became the industry standard, and now over 100,000 organizations run it today.

But the original dbt engine—built in Python—has its limits. Parse times grew with project size. The execution layer had no understanding of the SQL it was running. Errors surfaced only after hitting the warehouse. A ground-up rewrite was needed.

That rewrite became the dbt Fusion engine: built in Rust, with native SQL comprehension and parse times up to 10x faster than the original engine. We launched Fusion last year and today, over 4,500 projects run on Fusion. But maintaining two engines meant confusing licensing, an all-or-nothing-feeling migration path, and real uncertainty for contributors, adapter maintainers, and partners about where to build. So this week, we changed that.

We open-sourced the Fusion runtime and released it as dbt Core v2.0 under the Apache 2.0 license. This means that the two-engine era is coming to an end, and every practitioner can enjoy the dbt experience they know on a faster, more scalable foundation. Consolidating to one engine also means that our commercial investments will directly drive improvements in the open-source distribution of dbt. This is the biggest open-source expansion that dbt has made in years.

Fusion extends dbt Core v2.0 in a new proprietary distribution with richer capabilities, such as SQL comprehension, column-level lineage, and instant feedback while you work.

dbt Core v2.0 is in alpha release, while the proprietary distribution is in preview. The most used adapters are supported at launch: Snowflake, BigQuery, Databricks, and Redshift. The path forward is simple: pip install dbt==2.0.0-preview.x for a single binary that brings together the open runtime, Fusion-powered capabilities, and access to platform-connected workflows.

Read more: dbt Core v2.0 is here

Announcing dbt State: Build what’s changed, skip what hasn’t

Every time a pipeline runs, it rebuilds everything, even tables that haven’t changed. You pay for every one of those compute cycles. Over time, this becomes a significant cost, not just in warehouse spend, but in time engineers spend managing job schedules, building sub-selectors, and orchestration around the inefficiency. Custom, manual workflows mean slower data and slower answers.

dbt State changes this. On every run, dbt State checks your metadata and model SQL to see what’s changed. When upstream data or code has changed, it builds the model. Otherwise, it skips the build by reusing existing state, cloning existing state, or auto-deferring (in development) to production state. In production, this results in an average of 30% reduction in warehouse compute and prevents breakage. In development, this means faster iterations without fear of costly mistakes.

CarGurus Vice President of Data Parag Shah put it simply:

The impact goes beyond compute savings. When you know you're only paying for new work, you stop rationing runs. Teams that used to schedule refreshes carefully, because more frequent runs felt wasteful, can now run as often as the business needs fresh data, without the fear of an expensive bill at the end of the month. And with orchestration logic living in the project rather than a spreadsheet of job definitions, engineers spend less time on maintenance and more time on what matters.

State-aware orchestration has been delivering cost savings to dbt platform users on Fusion during preview. dbt State opens that capability to every dbt user: running locally on dbt Core (1.7+) or the dbt platform, in your orchestrator of choice, true to open data infrastructure principles. Available now in Preview: get started today.

Want to learn more?

Join us for a live virtual event on July 15th to see dbt State in action with a real customer story and answers to the questions practitioners always ask before they deploy. Save your seat now.

Announcing dbt Wizard: an AI agent built for analytics engineering

Coding agents are good at writing decent code. They're less good at writing code that knows your dbt project: code that respects your upstream models, doesn't break downstream dependencies, and handles the governance requirements your team has spent years building. The agent generates something plausible, but you spend the next hour verifying it.

Analytics engineering is not the same as software engineering. You're not just editing files. You're reasoning about lineage. You're aware of what breaks three models later. You're accountable when something goes wrong in production. Generic tools weren't built for that context.

dbt Wizard is.

dbt Wizard is an AI agent built specifically for the analytics engineering workflow: investigating, building, validating, and shipping. It's grounded in your dbt project natively. That means it knows your lineage, your contracts, your tests, and your metric definitions before it writes a single line. It knows which tool to call. It validates its own work. It shows you what changed and why. The difference this makes is concrete.

dbt Wizard is available in two surfaces: inside the dbt platform and from the terminal via dbt Wizard CLI for teams developing locally. It works across Snowflake, BigQuery, Databricks, Redshift, and every other dbt-supported warehouse. Get started today.

Want to learn more?

Join us for a live virtual event on July 22nd to see dbt Wizard in action across the CLI and dbt platform—real use cases, real analytics teams using it today, and answers to the questions you'll have after watching the demo. Save your seat now.

What’s next?

For data teams, the question has always been: how do we do more with what we have? Better pipelines, smarter infrastructure, less time managing things that should manage themselves.

That's what we're building. We’re at Snowflake Summit all week. Come see us at our booths to learn more and see these features in action.

Not at Snowflake Summit, or still have questions? On June 25th, Tristan Handy (President and co-founder, Fivetran & dbt Labs) and Taylor Brown (COO and co-founder, Fivetran & dbt Labs) are hosting a live virtual event to walk through the merger, what's shipping in dbt, and what it means for your stack, and then taking your questions live. This is the most direct access you'll have to the people making these decisions. Save your seat today.