dbt v2.0 is GA

After 18 months of engineering, reverse-engineering, de-engineering, and re-engineering, the dbt Fusion engine has graduated into General Availability under its new name: dbt. (Read more about that here). This complete rewrite of dbt solves a number of longstanding problems in dbt v1's implementation, and lays the foundations for another decade of progress. Before:

• dbt didn't understand the SQL it was generating, so it couldn't warn about invalid code without executing the code and consuming compute resources.
• At large scale, dbt could take as long as 20 minutes to parse a project before any execution could begin.
• dbt's artifacts made interoperability difficult, with enormous JSON files being the only way to communicate from one product to another.
• dbt docs was unable to work for many teams due to scaling and performance issues.

The new dbt v2:

• Includes rich SQL comprehension and the ability to catch code mistakes before they hit the warehouse, saving developers time and money and providing verifiable loops for agents.
• Is built for speed throughout, by moving to an optimized Rust binary and using modern technologies like ADBC. We've seen projects that used to take 20 minutes to parse now complete in less than one, and more normal-sized projects will also see a big speedup in daily usage (such as 2x or more faster compilation).
• Introduces the dbt Information Schema which describes an entire project as standard Parquet files. This can reduce file sizes by over 10x while providing richer data, and enables speedy querying through dbt show --info, external tools like DuckDB, and the brand new checks feature.
• Includes a brand new version of dbt docs, which is much more scalable.

The biggest new features

Find your (and your agents') mistakes faster

Code is being generated faster than ever thanks to agentic coding tools. Despite improvements to frontier models, I still see agents writing SQL they wish would work instead of being grounded in reality from the outset. Unlike languages like TypeScript or Rust – which have a compiler to catch mistakes as soon as they're written – the only way to catch a SQL mistake is to run it against the warehouse and see if it works.

Or, at least, it used to be the only way to catch a mistake. dbt v2 adds a local compiler to SQL for the first time. It's basically a form of harm reduction: if you're going to make up a column name, at least finding out you're wrong shouldn't cost money.

dbt proactively finds these mistakes by emulating the behavior of your specific database. It takes all the sources, UDFs, seeds and vendor-specific functions that make up your project and checks what would happen if the model was executed.

Specifically, dbt produces a logical plan (just like the one your database prepares before executing a query) – if it can't produce the logical plan, then there's something wrong with the query. If you're new to the fundamentals of SQL comprehension, the technical underpinnings or what product experiences logical plan analysis can unlock, check out the linked articles from last year.

How a compiler (Level 2 comprehension) sees a query

In some ways, dbt's static analysis is even more capable than the system built into your warehouse itself. Your warehouse can only evaluate the single query in front of it at any given moment; dbt knows that despite a query remaining valid on its own after removing a column, it would break 4 downstream models when deployed.

If you're coming from a large existing dbt project, baseline mode (enabled by default) provides an easy on-ramp to these static analysis features. Move up to strict static analysis to get the most features and strongest quality assurances.

Speed

For teams with large, highly customized dbt projects, slow project parsing can be a big blocker to getting into a flow state. dbt v2 introduces some new ways to increase performance:

1. It's faster on its own, thanks to its Rust underpinnings. My benchmarking project with 10k nodes takes 70 seconds to compile on dbt 1.12.0, and just 17 seconds on dbt v2.
2. One of the slowest parts of a dbt invocation is writing JSON at the end of a job. Add --no-write-json to your commands (or use the DBT_ENGINE_WRITE_JSON=0 environment variable) and switch to Parquet files (--write-index) to get richer data in smaller files.
3. It's easier to track down performance issues by looking at the OTel logs (coding agents loooove an OTel log). For example, we removed 3 minutes of redundant model compilation time from our internal analytics project by removing excessive introspection from some of our models.

Of course, the fastest execution is the one you don't do, which is where dbt State comes in. It keeps track of whether the model you're executing already exists in your target schema (so can be skipped) or exists in a different schema (so can be cloned instead of re-executed from scratch). dbt v2 integrates seamlessly with dbt State - activate your free trial with dbt build --manage-state.

A foundation that's ready to scale into the agentic era

Any tool reflects the context it grows up in. The original dbt started small and scrappy, and the foundations it was built on (Python, Jinja, JSON, vibes) were great choices for an internal tool used by a consulting company looking to streamline its work. As we built this new version of dbt, we knew that it would be used for Serious Data Work at Significant Scale. Which means we made different, more future-looking choices:

• ADBC and the Arrow ecosystem are the modern way to connect to databases and transfer data.
• Parquet files can represent the same information you'd find in a manifest.json in a fraction of the file size, and you can read a subset of the file instead of parsing the entire thing.
• Rust is a less forgiving language than Python's loosey-goosey approach to types, but in exchange you get phenomenal performance characteristics and compiler errors that make it harder to introduce bugs into dbt itself.
• Above all, building a SQL compiler into the heart of dbt is critical. It provides new fundamental capabilities which we are already using in interesting ways (column-level lineage, strict static analysis and type-aware function checking), and can continue to use for other features in the future.

Query your project itself

I mentioned above that we're leaning into the Parquet file format. It's used behind the scenes to help power strict static analysis, but the much bigger news is that we're also introducing a new contracted interface into your dbt project's metadata – the dbt Information Schema – which exists as a series of Parquet files itself.

Once you have information about your dbt project and the ability to run queries against it, you're right in the sweet spot of analytics engineering. Connect with DuckDB, use dbt show --info or the brand new native checks feature and you can do anything you can imagine:

• Identify models with dead columns, or staging/intermediate models which are never used in downstream layers
• Find the models with the least test coverage
• Enforce naming, ownership, or materialization conventions as code
• Let your agent look up model lineage, execution history or the blast radius of a proposed change instantly

A modern dbt docs experience

The original dbt docs started cool, moved into being outdated, and has (almost) swung all the way around to being vintage. I like imagining that there's a group of people who meet up on a Saturday morning to show off their lovingly maintained index.htmls or their tuned up catalog.json files.

But for the rest of us, there's a new docs site built on top of the dbt Information Schema, which scales to arbitrarily large projects and has the same entrypoint as before: dbt docs generate && dbt docs serve.

We've embedded the WASM distribution of DuckDB to look up relevant slices of project metadata from the Parquet artifacts on-demand. This is what makes the high performance possible, and has the bonus of enabling deployment as a static site (just like the old version of dbt docs).

Installation instructions

Officially, if you're coming from v1 of dbt, I should encourage you to use the pip installation flow. It's easy to drop it into your existing workflow (instead of pip install dbt-<adapter> , just do pip install dbt instead). This is a good idea if you're using multiple other Python-based data tools alongside dbt, and you want to keep everything sequestered. The new dbt binary will get installed safe and snug inside of your virtual environment. Here's the installation docs for that.

But the new dbt is not actually a Python project! We don't have to faff around with virtual environments anymore! So my personal recommendation is to go with a package manager (brew, winget) or the curl-based installation if you can. Two big reasons:

• dbt will always be available from your CLI, without having to first activate a virtual environment. This makes it easier to integrate with other tools that want to use dbt, such as the VS Code extension or your AI agent of choice.
• It makes updates self-contained: just run dbt system update and you'll get the latest improvements automatically (curl-only).

What's next for dbt?

A few years ago, we thought dbt was approaching feature completeness. Since then, two big AIs have shaken up the data ecosystem:

• Artificial Intelligence has increased the demand for trusted, machine-comprehensible data.
• Apache Iceberg has made it possible for data teams to control their destiny to a greater level than ever before.

With a view towards both, we're building and championing Open Data Infrastructure. Make sure you check out today's dbt Summit keynote and tomorrow's Community keynote to learn more about what it means for you. There's new exciting things to do, and dbt practitioners are remarkably well suited to doing them (have you ever noticed that context engineering and analytics engineering have a lot in common?)

You can expect dbt to keep growing and evolving, and you can help shape that evolution in the same ways as before: by opening issues, discussions, or pull requests on GitHub and by sharing what you're learning with the rest of the community.