Weaver vs dbt

dbt has a mature transformation ecosystem and a cross-platform design. Weaver focuses on coordinating Lakehouse work, Warehouse SQL, native Semantic Models and Reports inside Fabric.

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 supported T-SQL references. Spark SQL Tables and Views declare their dependencies explicitly; they still use native SQL rather than a macro layer.

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 installed definitions, load and model-refresh outcomes, validation results and consumer bookmarks 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.

Native semantic models and Reports

Weaver deploys PBIP/TMDL definitions, applies shared modelling rules, binds Reports to their model and runs DAX validations.

dbt does not deploy native Power BI models or Reports. Its Power BI connector queries the dbt Semantic Layer; it is a different integration.

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
Power BI semantic models and Reports
Deploy native PBIP/TMDL models and Reports	✓	✕not part of dbt-fabric deployment
Apply native TMDL modelling rules and compose model variants	✓	✕dbt semantic models define its own metrics layer
Validate DAX against Lakehouse or Warehouse SQL	✓	✕not a dbt-fabric validation target
Order model refreshes with managed source loads	✓	✕Power BI refresh is outside the adapter run

Where each tool fits

dbt suits teams standardising transformations across platforms. Weaver suits teams that want source loading, native Power BI deployment and managed operational state together in Fabric.

Choose your entry route

Start with Fabric Python or SQL, or deploy an existing Power BI project.

Get started

See what each command does

Build, load, test and health in plain language.

How it works

dbt’s Power BI integration lets Power BI query the dbt Semantic Layer. It does not provide the native model, Report and DAX lifecycle compared above.

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