Weaver vs dbt

dbt is a strong choice when the main job is modelling transformations. Weaver is aimed at Fabric projects where Python, files, Lakehouses, Warehouses, loading and recovery all need to work together.

Differences that change the work

Lakehouse and Warehouse in one project

Weaver can put Python and Delta work in a Lakehouse, T-SQL in a Warehouse and the shortcut between them in the same project.

dbt uses separate Fabric adapters for Warehouse and Spark work. The order between the two has to be managed elsewhere.

Dependencies from ordinary Python and SQL

Weaver reads Python imports and SQL table references. You do not repeat them in another pipeline or replace the SQL references with framework-specific syntax.

dbt uses ref() and source() to declare those relationships.

Build the structure without loading the data

weaver build creates or changes tables, views, shortcuts and load code. weaver load runs the data work separately.

A dbt model is created and populated by the same run.

Run results stay in Fabric

Weaver records what was built, what loaded, what failed and where each load should continue in a Fabric Warehouse.

dbt Core writes files such as manifest.json and run_results.json. State comparison uses a previous manifest.

Branch the Fabric data with Mirror

Weaver can give a development project the current production data without copying every table. Build the parts you need to change and leave the rest behind views or OneLake shortcuts.

dbt-fabric documents table cloning within one Warehouse. Mirror works across the Lakehouses and Warehouses in the Weaver project.

Feature comparison

✓ yes ◐ partly, see the note ✕ no

Capability	Weaver	dbt on Fabric
Fabric projects
One project containing both a Fabric Lakehouse and Warehouse	✓	✕ Warehouse and Spark use separate adapters and targets
Fabric shortcuts represented as dependencies	✓	✕ not graph resources
Same project files used with different development and production items	✓	◐ targets and database configuration change relation locations
Create a development branch of Fabric data with Mirror	✓	◐ table clone is documented within a Warehouse
Authoring
Ordinary SQL references, without dependency templating	✓	✕ dependencies use `ref()` and `source()`
Dependencies read from Python imports	✓	✕ Python models use `dbt.ref()`
Python loaders for APIs, SFTP, archives and files	✓	✕ Python models produce relations
Warehouse identity column declared with the table	✓	✕ no documented model configuration
Build and runs
Deploy physical structure without loading data	✓	✕ model materialisation creates and populates the relation
Build and run results kept in Fabric for later commands	✓	◐ dbt Core carries state in run files
Remember where each incremental load should continue	✓ bookmarks	◐ incremental models usually query the target
Report what is current, stale, failed, blocked or missing	✓	◐ source freshness covers declared sources
Independent branches continue after a failure	✓ with fault-tolerant loading	✓ descendants are skipped
Loading data
Work out inserts, updates and deletes before writing	✓	◐ depends on incremental strategy
Invalid incoming rows refused and retained with a reason	✓	✕ tests detect invalid target rows after loading
Threshold stops an unusually large change before writing	✓	✕ not a built-in model policy

Where each tool fits

dbt is built around transformation models across many data platforms. Weaver is built for Microsoft Fabric projects that include Python loaders, files, Lakehouses, Warehouses, cross-item dependencies, data loading and recovery.

Run the Sales example

Build and load one project across a Lakehouse and Warehouse.

Get started

See what each command does

Build, load, test and health in plain language.

How it works

Sources: dbt-fabric, dbt-fabricspark and Microsoft Fabric documentation.