dbt 2.0 and SQL Quality

dbt 2.0 is the next generation of the dbt engine: it parses a project in a fraction of the time, catches type and column mistakes before anything touches the warehouse, and adds run options that dbt Core does not have. Moving a live project onto a new engine is also the kind of change teams put off, because nobody wants to find out what breaks on a Monday morning.

dbdeux removes that risk. You can run dbt 2.0 alongside dbt Core, check any environment for readiness without changing anything, and switch one run, one job, or one environment at a time when you are ready.

Environment · production · dbt 2.0 readinessOn the environment, click Check dbt 2.0 readiness: a parse only, nothing is built

1 · Readiness checkNot checked

Check dbt 2.0 readiness

models/marts/fct_orders.sql2

42:7Column order_total is not defined in the upstream model

61:3Deprecated config key persist_docs; use docs instead

models/staging/stg_payments.sql1

18:11Type mismatch: comparing STRING to NUMBER

macros/cents_to_dollars.sql1

4:1Macro argument precision is never used

2 · Open in editorfct_orders.sql · 42:7

40 select

41 o.order_id,

42 o.order_total as order_total,

43 c.customer_id

44 from {{ ref('stg_orders') }} o

Nothing runs against your warehouse during a check, and the environment keeps its own engine until you change it.Check passed. Every past check stays in the history below.

3 · Engine and run optionsdbt Core 1.8

dbt Core 1.8default

dbt Core 1.10

dbt 2.0faster parse, run options

Continue on error · downstream models keep building when a parent fails; the run still reports as failed

Skip redundant tests · drop tests dbt can prove already pass, on dbt build steps

Choose Your Engine

Three engines are available everywhere a run starts: the editor run bar, the job wizard, and each environment's default.

Engine	Where it stands	Warehouses
dbt Core 1.8	Default, stable	All connected warehouses
dbt Core 1.10	Latest Core release	All connected warehouses
dbt 2.0	Next-generation engine	Snowflake, BigQuery, Databricks, Redshift, MotherDuck. PostgreSQL and Microsoft Fabric are experimental

The engine picker shows only what applies to the current environment. If an environment's warehouse has no dbt 2.0 adapter yet, dbt 2.0 is listed but cannot be chosen, with a note explaining why, so nobody starts a run that was never going to work.

Wherever an engine is shown, the label tells you where it came from: the value set on the job, the environment's default, or the platform default. Older names for the 2.0 engine, such as "Fusion" or "2.0 preview", are still recognized in existing jobs and resolve to dbt 2.0.

Check Readiness Before You Switch

Every environment has a dbt 2.0 readiness tab. Click Check dbt 2.0 readiness and dbdeux parses your project with the dbt 2.0 engine against that environment's connection, then shows every issue 2.0 would raise.

• Nothing is built and nothing changes in your warehouse. The check reads your project and your connection's metadata and stops there.
• Your current engine stays put. The environment keeps running on whatever engine it uses today until you choose dbt 2.0 yourself.
• Grouped by file, errors first. Each finding shows the file, the line and column, and a plain description. The same file with three problems is one group, not three scattered rows.
• Open in editor on any finding lands your cursor on that exact line in the Cloud IDE, with the right branch and file open.
• Warnings never block. An environment with only warnings is marked Ready. Deprecated settings and unused arguments are shown so you can tidy them, not to stop you.
• History stays with the environment. Each check is kept with its result, count, and who ran it, so you can see a project go from 14 findings to Ready over a week.

If the environment's warehouse is not supported by dbt 2.0, the tab says so and suggests running the check against an environment on a supported warehouse.

:::tip Where to start Run the check on your development environment first, fix what it lists, and only then run it on staging or production. Because the check never builds anything, running it on production is safe at any hour. :::

dbt 2.0 Run Options

When dbt 2.0 is the selected engine, two extra options appear beside the run and job commands. They are dbt 2.0 features, so they stay hidden for Core 1.8 and Core 1.10, whose behavior does not change.

Option	What it does	Why you would want it
Continue on error	When a model fails, its downstream models keep building instead of being skipped. The run still reports as failed.	One broken staging model no longer leaves fifty marts untouched for the night. You see every real failure in one run instead of one per morning.
Skip redundant tests	On dbt build steps, tests that dbt can prove already pass from upstream constraints are skipped.	Shorter, cheaper builds with no loss of coverage. A not_null test on a column that is not_null by construction does not need a query.

Both options work the same way for a one-off run from the editor, a scheduled job, and a PR build, and the run log records which options were on.

Readiness in Pull Requests

Slimmer CI can run the same readiness check on every pull request. Turn on dbt 2.0 readiness report in the project's Slimmer CI settings and each PR build gets a readiness tab with findings grouped by file and Open in editor on every row.

It is a report, not a gate: the PR result and your Git provider check are unchanged whether the project is ready or not. Use it to watch a migration converge, or to make sure nobody reintroduces a pattern you already removed. See Slimmer CI.

SQL Lint and Format

Style arguments in code review are expensive and rarely about the data. dbdeux builds SQLFluff, the standard SQL linter for dbt projects, into the editor and into pull requests, so the rules are applied by a machine and people review logic.

Editor · models/marts/fct_orders.sqlOpen a model and click Lint: this file, all open SQL files, or the whole project

LintFormatthis file · open SQL files · whole projectNot linted

Your SQLsaved

1SELECT o.order_id,o.customer_id ,

2 sum(p.amount) AS total

3from {{ ref("stg_orders") }} o

4LEFT join {{ ref("stg_payments") }} p

5 on o.order_id=p.order_id

6group by 1,2

Problemsclick a row to jump

L1CP01Keywords must be consistently lower case

L1LT04Commas should be followed by a space

L3AL05Table alias should use the AS keyword

L5LT01Expected single space around operator

L6AM06Inconsistent column references in group by

Slimmer CI · PR #214 · SQL lint tab
3 files linted, 1 finding. Report only: the PR result and the git check are unchanged.

In the Editor

Two actions sit in the editor toolbar and the command bar:

• Lint checks the current file, all open SQL files, or the whole project. Findings appear as markers on the offending lines and as rows in the Problems tab, each with the rule name and a one-line explanation. Click a row to jump to it. Lint never changes a file.
• Format applies every fix the rules know how to make: keyword case, commas, spacing, aliases, indentation. Findings that need a judgment call, such as an inconsistent group by, stay in the Problems tab so you can decide.

Format is deliberately careful with your work:

• It only formats saved files. If a file has unsaved edits, the editor asks you to save first rather than formatting a version you are not looking at.
• The result is applied only when the file in the editor still matches what was formatted. If you kept typing while it ran, nothing is overwritten; run Format again when you are done.
• Only .sql files are considered. YAML, Markdown, and Python files are left alone.

Your project's own .sqlfluff configuration is honored, so the rules in dbdeux are the rules your team already agreed on.

In Pull Requests

Turn on SQL lint report in the project's Slimmer CI settings and every PR build lints the SQL files the PR touched and shows the findings in a SQL lint tab, grouped by file with Open in editor on every row. Like the readiness report, it never changes the PR result or your Git provider check, and it never rewrites a file: the author decides whether to click Format.

Why This Is Better

	dbdeux	Running dbt 2.0 yourself	dbt Cloud
Try 2.0 without changing anything	One click per environment, parse only, history kept	Install a second CLI, keep two profiles in sync, read the terminal	Switch the environment version and run to find out
Jump from a finding to the line	Open in editor, right branch and file	Copy the path, open your IDE, find the line	Terminal output only
2.0 and Core side by side	Per run, per job, per environment	Separate virtual environments	One version per environment
Readiness and lint on every PR	Report tabs on the PR build, report only by default	Write and maintain your own CI steps	Not built in
Format safety	Saved files only, never overwrites edits in progress	Editor plugin dependent	Not built in

Related

• Environments for where the readiness tab and the default engine live
• Job Scheduling for choosing the engine and run options on a job
• Slimmer CI for the PR readiness and SQL lint reports
• Atlas Catalog for dbt 2.0 user-defined functions in the catalog