dbt Fusion Engine and dbt Wizard
Adopt the next-generation dbt Fusion engine (Rust-based, up to 30x faster parsing) for local Redshift development, understand dbt Core v2 and its open-source foundations, and use dbt Wizard CLI — the AI agent built specifically for analytics engineering — to author, refactor, investigate, and validate dbt models grounded in your full project context.
dbt Fusion Engine and dbt Wizard
The analytics engineering toolchain is undergoing its most significant shift since dbt itself was created. Two technologies define this new era: the dbt Fusion engine — a Rust-based rewrite that replaces the Python execution layer with SQL-aware, dramatically faster compilation — and dbt Wizard — an AI agent that understands your full dbt project before it writes a single line. Both are available to self-hosted, open-source dbt users.
The Ecosystem in June 2026
Before diving into installation, understand the current landscape:
dbt Core v2 is the open-source Apache 2.0 foundation that the dbt Fusion engine builds on. It delivers a faster, Rust-based runtime while preserving the dbt experience practitioners already know. It is currently in alpha.
dbt Fusion is distributed under the Elastic License Version 2 (ELv2). dbt Core remains under the open-source Apache 2.0 license and will continue to be maintained indefinitely.
What this means for self-hosted dbt-Redshift users:
- You can install the Fusion CLI (
dbtf) for free — get faster parsing and compilation without any license restrictions for self-hosted use. - dbt Wizard CLI is in public beta and free to use with your own OpenAI API key (BYOK).
- dbt-core v1.x continues to be fully supported and is the production-stable choice for large projects.
dbt Fusion Engine
What Fusion Changes
The dbt Fusion engine gives your team up to 30x faster performance and comes with different features depending on where you use it. It powers both engine-level improvements (like faster compilation and incremental builds) and editor-level features (like IntelliSense, hover info, and inline errors) through the LSP through the dbt VS Code extension.
| Capability | dbt-core v1.x | dbt-core v2 (Rust OSS) | Fusion engine |
|---|---|---|---|
| Parse speed | Baseline | Up to 30× faster | Up to 30× faster |
| SQL rendering (Jinja) | ✅ | ✅ | ✅ |
| SQL parsing (AST) | ❌ | Partial | ✅ |
| Column-level lineage | ❌ | Partial | ✅ |
| LSP / IntelliSense | ❌ | ❌ | ✅ (via VS Code extension) |
| Parquet artifacts | ❌ | ✅ | ✅ |
| Strict config validation | ❌ | ✅ | ✅ |
| License | Apache 2.0 | Apache 2.0 | ELv2 |
v2.0 introduces a strict, well-defined language specification. It becomes impossible to silently misconfigure a key — a typo'd desciptin instead of description is caught rather than ignored.
Redshift Adapter in Fusion
The Fusion engine launched support for Redshift (along with Snowflake, Databricks, and BigQuery) as part of the preview release. The Redshift ADBC driver was released in September 2025, replacing the Python redshift-connector with an Arrow-native data transfer layer.
For BigQuery and Redshift, Fusion respects user-set threads to manage rate limits and concurrency constraints. Setting --threads 0 or omitting the setting allows Fusion to dynamically optimize.
Installing the Fusion CLI
# macOS / Linux — one-line installer
curl -fsSL https://fusion.getdbt.com/install.sh | sh
# Reload shell after installation
source ~/.zshrc # or ~/.bashrc
# Verify — Fusion installs as both 'dbt' and 'dbtf'
dbtf --version
# dbt Fusion 1.0.0-preview (Rust runtime)
# If you have dbt-core installed, use dbtf to avoid conflicts
dbtf --version # Fusion
dbt --version # dbt-core (unchanged)On Windows (PowerShell):
# Windows installer
iwr -useb https://fusion.getdbt.com/install.ps1 | iex
# Verify
dbtf --versionRunning Fusion Against Redshift
Your existing profiles.yml works without modification — Fusion reads the same file:
# Same commands, dramatically faster parse + compile
dbtf debug # test connection
dbtf compile --select staging # compile without running
dbtf run --select +fct_orders # run models
dbtf test --select marts # run tests
dbtf build --select +marts # build + test in DAG orderFusion-Specific Features on Redshift
1. Strict Key Validation
Fusion catches typos in YAML configs that dbt-core v1.x silently ignores:
# This silently does nothing in dbt-core v1.x
# Fusion raises an error: "Unknown config key 'destription'"
models:
- name: fct_orders
destription: "One row per order" # ← typo caught by Fusion
config:
materialzed: table # ← typo caught by Fusion2. --sample Flag (Fusion preview)
Run your full SQL logic against a sample of rows — without modifying your models:
# Run fct_orders against 1% sample of upstream data
dbtf run --select fct_orders --sample 0.01
# Use for fast iteration during model development
dbtf build --select +new_mart_model --sample 0.05This is particularly useful for Redshift Serverless where scanning full tables during development incurs unnecessary cost.
3. Incremental Builds (Fusion State Cache)
dbt State (preview) acts as a caching layer for data pipelines, building only what has changed. The company claims this can reduce infrastructure costs by 30 percent or more.
Fusion maintains a local state cache that tracks which models need rebuilding — like Slim CI, but for local development:
# First run — builds everything, saves state
dbtf run --select +marts
# Second run — only rebuilds models whose SQL changed
dbtf run --select +marts --state ./target
# Output: 3 models changed, 47 models skipped (cached)4. VS Code Extension for Redshift Development
Install the dbt VS Code extension for Fusion-powered IDE features:
1. Open VS Code
2. Extensions → search "dbt Power User" or "dbt (official)"
3. Install the official dbt Labs extension
4. Open your dbt project folder
5. The extension auto-detects Fusion if dbtf is in PATH
Features active on Redshift:
- IntelliSense:
{{ ref('autocompletes with model names from your project - Hover info: hover over a
ref()to see the model's description and columns - Inline errors: typos in YAML and broken
ref()calls highlighted without running - Column lineage: click a column to trace it upstream/downstream
5. Parquet Artifacts for Metadata Queries
With Fusion, manifest.json and catalog.json are also emitted as Parquet:
# Query your dbt project metadata with DuckDB — no JSON parsing needed
import duckdb
con = duckdb.connect()
# Find all models over 60 seconds in the last run
slow_models = con.execute("""
SELECT
name,
execution_time_seconds,
schema_name,
materialization
FROM read_parquet('target/run_results.parquet')
WHERE resource_type = 'model'
AND execution_time_seconds > 60
ORDER BY execution_time_seconds DESC
""").df()
print(slow_models.to_string())dbt Wizard CLI
What dbt Wizard Is (and Is Not)
The dbt Wizard CLI is a terminal-native AI agent purpose-built for analytics engineers. Unlike general-purpose coding agents that hallucinate joins, break downstream refs, and ignore your contracts, Wizard is grounded in your dbt project's compiled state, lineage graph, and semantic definitions from the first prompt.
dbt Wizard is an AI agent purpose-built for governed data development in dbt. Unlike general-purpose coding agents, it understands your dbt project through a native metadata engine — a structured index of lineage, model health, tests, contracts, run results, and semantic definitions. Think of it like a map of your city: dbt Wizard knows how everything connects before it starts, rather than walking every street to figure out the layout.
The key difference from using Claude, Copilot, or Cursor in a dbt project:
| Capability | General AI coding agent | dbt Wizard |
|---|---|---|
| Knows your model grain | No | Yes |
| Respects model contracts | No | Yes |
| Understands ref() lineage | No | Yes |
| Validates changes before showing diff | No | Yes |
| Knows your MetricFlow definitions | No | Yes |
| Updates downstream refs on rename | No | Yes |
Of the latest set of 75 ADE-bench tasks, dbt Wizard scores 76% and showed significant improvement on hard tasks over other agentic systems. The native understanding of dbt projects dramatically improves agent performance, especially as project sizes increase.
Installing Wizard CLI
# Install via pip (uses your own OpenAI API key — BYOK)
pip install dbt-wizard
# Configure your API key
wizard providers configure openai
# Enter your OPENAI_API_KEY when prompted
# Verify
wizard --versionCore Wizard CLI Commands
# Get a project overview — Wizard reads your full project state first
wizard /overview
# List available commands
wizard /
# Start an interactive session (recommended for complex tasks)
wizardUse Case 1: Building a New Model
# In your dbt project directory
wizard
> Build a new fact table fct_customer_revenue that aggregates
> total revenue, order count, and average order value per customer
> per month. It should join fct_orders with dim_customers. Use
> the customer_id distribution key. Include a model contract.
# Wizard:
# 1. Reads your project manifest to find fct_orders and dim_customers
# 2. Checks their schemas (columns, types, contracts)
# 3. Writes the model SQL
# 4. Writes the schema.yml with contract and tests
# 5. Compiles and validates before showing you the diff
# 6. Waits for your review before writing filesWizard output workflow:
Use Case 2: Refactoring an Existing Model
wizard
> Refactor stg_orders to rename the column raw_status to status_code,
> then update fct_orders and any other downstream models that reference
> raw_status. Also update all tests and documentation.
# Wizard:
# 1. Finds all models downstream of stg_orders using lineage graph
# 2. Identifies every reference to raw_status
# 3. Updates stg_orders, fct_orders, and all affected YAML files
# 4. Compiles the full affected subgraph to validate
# 5. Shows a multi-file diffUse Case 3: Investigating a Failure
wizard
> The last dbt run failed on fct_orders with a unique test failure.
> Investigate and suggest fixes.
# Wizard:
# 1. Reads run_results.json from ./target/
# 2. Identifies the failing test and which rows caused it
# 3. Traces back through the lineage to find likely causes
# 4. Suggests fixes (deduplication logic, source data issue, etc.)Use Case 4: Generating Documentation
wizard
> Generate missing column descriptions for fct_orders. Use context
> from upstream models and existing descriptions where available.
# Wizard:
# 1. Reads fct_orders schema to find undocumented columns
# 2. Traces each column back to its source via lineage
# 3. Reads existing descriptions from upstream models
# 4. Generates context-aware descriptions
# 5. Writes to schema.yml after your approvalUse Case 5: Writing Unit Tests
wizard
> Write unit tests for the status mapping logic in fct_orders.
> Cover all raw status codes including edge cases like null and
> unexpected values.
# Wizard:
# 1. Reads the model SQL to understand the mapping logic
# 2. Reads the contract to understand expected output types
# 3. Generates the unit_tests YAML block with given/expect rows
# 4. Validates the tests compile before showing the diffWizard Configuration: Project Instructions
Give Wizard standing instructions for your project so every session starts with context:
<!-- .dbt-wizard/instructions.md -->
# Project: Analytics Platform
## Conventions
- All mart models must have a model contract enforced: true
- Distribution key should match the primary join key
- All fact tables use compound sort key with the date column first
- Status columns map raw codes using the seed/status_mapping.csv reference
- All new models require at least: not_null, unique tests on PK
- Use docs blocks for descriptions longer than one sentence
## Naming
- Staging: stg_<source>_<entity> (e.g., stg_oms_orders)
- Intermediate: int_<entity>_<transformation> (e.g., int_orders_enriched)
- Marts: fct_<entity> (facts), dim_<entity> (dimensions), rpt_<entity> (reports)
## Redshift Config Defaults
- Staging: materialized=view, bind=false, backup=false
- Marts/Facts: materialized=table, backup=true
- Reporting: materialized=materialized_view, auto_refresh=true
## Do Not
- Do not use SELECT * in mart models — list columns explicitly
- Do not join raw sources directly in mart models
- Do not hardcode schema names — use ref() and source()# Wizard reads this file automatically at the start of each session
wizard /overview
# "Reading project instructions from .dbt-wizard/instructions.md..."Wizard Threads: Organized Long-Running Work
For multi-session work (e.g., a migration that spans days), use named threads:
# Start a named thread
wizard --thread "redshift-to-serverless-migration"
> We're migrating 150 models from provisioned Redshift to Serverless.
> Start with the staging layer. Update all profiles and configs.
# Resume the thread in a future session
wizard --thread "redshift-to-serverless-migration" --resumeWhen to Use Fusion vs. dbt-core v1.x
For large dbt Core infrastructures (over 3000 models): It is probably safer to wait for the final version (General Availability). The risk of losing critical features is still too high. For small and medium-sized projects (up to 500 models): It is strongly recommended that you test the migration tool in a development environment.
Fusion Migration Checklist
# 1. Install Fusion CLI
curl -fsSL https://fusion.getdbt.com/install.sh | sh
# 2. Run the built-in migration audit tool
dbtf migrate audit --project-dir .
# Output: list of issues to fix before Fusion is fully compatible
# Common issues on Redshift projects:
# - Interleaved sort keys (unsupported in Fusion DDL currently)
# - Some custom materializations using internal dbt-core Python APIs
# - Macros using run_query() without execute guard
# 3. Fix flagged issues, then verify
dbtf compile --select staging
# 4. Compare output with dbt-core v1.x
dbt compile --select staging --target dev > /tmp/core_compiled.txt
dbtf compile --select staging --target dev > /tmp/fusion_compiled.txt
diff /tmp/core_compiled.txt /tmp/fusion_compiled.txt5 Practice Questions
What license is the dbt Fusion engine distributed under, and what restriction does it impose?
On Amazon Redshift, how does Fusion handle thread parallelism differently from Snowflake?
What does the `--sample 0.01` flag in the Fusion CLI do?
What fundamentally separates dbt Wizard from using a general-purpose AI assistant (Claude, Copilot, Cursor) in a dbt project?
What is the purpose of `.dbt-wizard/instructions.md` in a project?
For a production dbt-Redshift project with 800 models, what is the recommended approach to Fusion adoption as of June 2026?
Key Takeaways
- The dbt Fusion engine is a Rust-based rewrite offering up to 30× faster parse and compile times. It ships as a free binary CLI (
dbtf) under the ELv2 license. - dbt-core v2.0 (Apache 2.0, currently alpha) is the open-source Rust foundation Fusion builds on — it includes strict key validation, Parquet artifacts, and faster parsing.
- The Redshift ADBC driver shipped in September 2025 — Fusion is production-compatible with Redshift provisioned clusters and Serverless.
- On Redshift, set
--threads 0or respect user-set threads (unlike Snowflake, where Fusion auto-optimizes). Use--sampleto develop against data subsets. - dbt Wizard CLI is a terminal-native AI agent grounded in your project's compiled state, lineage, contracts, and run results — not a generic coding assistant.
- Wizard validates changes by compiling them before presenting a diff, preventing broken refs and contract violations from reaching your codebase.
- For projects under 500 models, test Fusion now. For 500–3,000 models, use Fusion in development and dbt-core v1.x in production. Above 3,000 models, wait for GA.
- Write
.dbt-wizard/instructions.mdto give Wizard persistent knowledge of your naming conventions, config defaults, and coding rules.