Fusion static analysis is getting a new default: baseline

[dataders]

Based on extensive community feedback from dbt Fusion's beta and preview periods, we're changing how static analysis works to optimize for the first-run experience when an existing dbt project upgrades to Fusion.

We're introducing a new level of static analysis called baseline, which will become the new default. In baseline mode, Fusion still validates your SQL, but it raises issues as warnings instead of blocking errors, so your runs can complete even if Fusion detects problems that would have stopped execution in strict mode (the previous default).

This is especially helpful when upgrading from dbt Core to Fusion for the first time: if your project already runs successfully in production, baseline lets you transition smoothly without the new static analysis checks unexpectedly breaking established workflows.

Now, teams can start getting benefits right away, then adopt stricter validation incrementally over time, which is conceptually similar to what some languages call "gradual typing".

If you want to go deeper on what a SQL compiler even is: check out this blog: The Levels of SQL Comprehension.

TL;DR

What's changing?

The static_analysis config is evolving to the following set of modes:

Mode	Status	Behavior
baseline	Default (new)	Fusion validates your code, but issues are raised as warnings and do not block execution.
strict (formerly on)	Available (renamed)	Fusion validates your code and raises errors for issues, which block execution.
off	Available (unchanged)	Fusion doesn't perform static analysis before sending queries to the warehouse.
unsafe	Removed	Previously suppressed non-deterministic analysis warnings. No longer necessary—we've removed unsafe static analysis warnings altogether.

What do I need to do?

Update the static_analysis config on your models:

Current config	Recommended new config	Why
off	baseline	Gets DevEx benefits without blocking project runs
on	strict	New name for the same behavior
unsafe	strict	Unsafe was still full strictness, just later in the validation pipeline. This now happens automatically.
not explicitly set	strict	When the default changes from on to baseline, your project will drop to baseline and lose some DevEx benefits (see below table).

Why baseline?

When we first shipped Fusion, we treated a clean compile with static_analysis: strict (formerly on) as the entry point for most of Fusion's new features and experiences. In practice, many real-world dbt projects that run successfully in dbt Core don't meet that bar on day one.

Some scenarios that consistently cause strict compilation to fail out of the gate:

• Non-standard customizations — custom materializations, hooks, complex macro patterns
• Limited warehouse permissions — e.g. developers can't SELECT from all upstream sources

Our updated goal is to make Fusion upgrades feel smooth for existing dbt Core projects, while still providing a clear path to adopt stronger guarantees over time. That's why we're introducing static_analysis: baseline as the new default.

What is baseline mode?

The below-linked docs page is a great resource, but it's worth going over the key concepts here.

A new concept: static analysis | dbt Developer Hub

Baseline mode is a less strict level of static analysis that:

• Validates the grammar and syntax of your compiled SQL
• Gives teams a path to upgrade first and move to strict when they're ready by issuing warnings instead of errors
• Unlocks VS Code extension features that were previously only available with strict

Additionally, it:

• Can continue analyzing even if a problem is detected in the middle of your DAG
• Reduces complexity by not requiring that source table schemas be downloaded and cached locally (more on that below)

Feature availability by static_analysis config

Feature	off	baseline	strict
Go-to-definition/reference (except columns)	✅	✅	✅
Table lineage	✅	✅	✅
YAML validation	✅	✅	✅
Render + preview SQL	✅	✅	✅
Unit tests	✅	✅	✅
Detect syntax errors	❌	✅	✅
Preview CTE results	❌	✅	✅
Go-to-definition/reference (columns)	❌	❌	✅
Automatic refactor column names	❌	❌	✅
Rich column lineage	❌	❌	✅
Detect data type and function signature errors	❌	❌	✅

Other things worth noting

Introspection consequences

Previously, the system assumed local schemas of your compiled models would be available, since users were compiling with strict. In baseline, we can no longer assume the full local schema is available and complete, so baseline uses the remote database as the source of truth—similar to dbt Core.

The practical result is that the Fusion compiler may sometimes flag incorrect queries resulting from introspective queries that come back empty. If you encounter this, you can:

1. Ignore the warning
2. Build the model locally
3. (coming soon) Use warn_error_options to disable the warning

For example, consider this query using the dbt_utils.unpivot macro:

select * from (
{{ dbt_utils.unpivot(
        relation=ref('example_model'),
        cast_to='integer',
        exclude=['order_id', 'customer_id'],
        field_name='product_type',
        value_name='quantity') }}
)

If the introspection query fails or returns no results, this renders to:

select * from (

)

This is invalid SQL and would normally produce a static analysis error. However, in baseline mode, the error is downgraded to a warning (see below). This behavior allows your project to continue running while still alerting you to potential issues with introspective queries.

dbt0101: no viable alternative at input '(
)'
  --> models/example_model.sql:17:1

Downloading of source schema

When static_analysis: on was the default, Fusion would automatically download the column types of all your source tables. Doing so gave Fusion the ability to:

1. Fully validate that models will run on the database without error
2. Perform rich column-level lineage analysis

In baseline mode, Fusion will not automatically download source schemas. This improves compile performance and reduces complexity, but at the expense of the above features.

We're exploring ways to reintroduce this metadata in baseline without bringing back the complexity of automatic schema downloads (see "What's next" later in this doc).

Unit tests

Unit tests now behave identically to dbt Core in a few ways:

• They run when static_analysis is off or baseline
• compile does not render a unit test's SQL into target/

What's next? We want your feedback!

Beyond "any questions?" here are some areas we're thinking about:

Beyond asking the warehouse, how might Fusion get column data type information?

What's more appealing for you and your team: the Fusion engine doing automatic schema inference, or user-provided schema?

First and foremost, we intend to add column-level lineage analysis to baseline mode in the near future. We know how we'll do this technically, but how it should behave and surface diagnostics when results are incomplete is where we need your input.

With automatic source schema downloads disabled in baseline, we don't have column names and types for sources at compile time. Given that, we see two paths to reintroduce this metadata:

1. Source schema declaration — Allow users to explicitly provide source schemas, and provide column-level lineage for columns derived from those schemas. At minimum, we will do this. See the in-depth GitHub discussion: Source schemas should be first-class, versioned artifacts · dbt-labs/dbt-fusion · Discussion #1042
2. Schema inference — We can also attempt to infer column names and data types from how sources are used throughout the project. However, select * projections are opaque, so we can't guarantee 100% coverage. When we tested this on Jaffle Shop, about 70% of columns were successfully deduced. The open question: would you want best-effort analysis done automatically, or explicitly opted into?

Warnings or errors

Once source schemas are back in place for baseline, we can layer on gradual schema and type analysis, which raises the question:

When these analyses fail, what should the severity be in baseline mode? Warn? Or error?

Is configuring on the node enough?

We also intend to introduce warn_error_options configurations into Fusion within the next month, which makes me think:

• Should we let you upgrade all SQL analysis issues to errors?
• Is it useful to upgrade only syntax issues but not schema, type checking, or function not found issues?

Lastly, today you'd need to apply static_analysis across all node types in your dbt_project.yml (e.g. models, seeds, analyses, etc.). Should we introduce a top-level static_analysis key? For example:

flags:
    static_analysis: strict

Beyond that, could you imagine having more fine-tuned control over how your static analysis checks work? Is that something you're interested in?