Inside dbt v2: how a rebuilt SQL engine makes linting up to 250x faster

Alexander Bogdanowicz, a dbt Labs engineering leader who manages the org behind dbt v2, spanning the adapters, growth, VS Code extension, and core engine teams, walked a packed room through the new developer experience in a live-demo session. He's worked on the underlying problem for about four years: two at dbt Labs, and two more at SDF, the company dbt Labs acquired that built much of the language comprehension technology behind v2.

dbt has always understood project configuration and how to orchestrate a DAG, ever since refs and sources let teams build one in SQL. What it never had, until v2, was an actual understanding of SQL grammar itself.

dbt v2 fixes that by rewriting the Jinja templating engine in Rust, giving dbt real semantic comprehension of the SQL and Jinja it runs. That rewrite unlocks a few new layers: incremental project state management (the thing powering fast compilation in the VS Code extension), baseline static analysis that always checks SQL is grammatically valid, and strict static analysis that catches errors locally before a project ever runs remotely.

In the demo, enabling the LSP linter in VS Code surfaced lint problems inline as Bogdanowicz edited a model, and running dbt lint from the terminal showed the same diagnostics. The linter ships with five new dbt-specific SQLFluff rules, including one that flags raw hard-coded table references instead of refs or sources, and one that flags OR conditions inside joins because they force unnecessary table scans.

dbt format and dbt lint --fix cleaned up dozens of violations automatically, leaving only the ones that needed a human judgment call. The headline number: dbt v2's linter is 40 to 250 times faster than standard SQLFluff on the same project.

The reason is that dbt v2 never runs the introspection queries that normally slow down linting, because its semantic understanding of SQL and Jinja fills in those gaps without ever hitting the warehouse.

dbt checks bring project-level assertions natively into SQL, replacing patterns that previously lived in Jinja-based tools like the dbt Project Evaluator package. Checks query an internal, project-generated "information schema" (covering models, docs, lineage, groups, macros, and metrics) through DuckDB, with configurable severities and selection filters so a check can be scoped to a single model.

They also run automatically as part of dbt build. Docs v2 is built on that same information schema and runs through DuckDB compiled to WebAssembly in the browser, so dbt docs generate and dbt docs serve produce a fast, statically hostable catalog.

Full column-level lineage is available as long as the project compiles with strict static analysis turned on. The VS Code extension's Compare Changes feature runs a live data diff between a modified model and its production version, and in the demo it caught an accidental 90,000-row drop caused by a single bad filter change.

Unit tests can now also compile down and run entirely on local DuckDB, with zero network calls, for Snowflake and BigQuery projects (currently an experimental feature). dbt v2 can additionally batch multiple not-null or uniqueness tests on one model into a single scan, cutting both compute and run time on large projects.

An audience poll found roughly 40 percent of the room had already tried dbt v2. Bogdanowicz closed by pointing people toward the private betas for dbt State and Lake Compute, calling dbt State "a free lunch" that pays for itself in saved compute.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →