Engineering across the Fabric estate.

Explore how Weaver handles Lakehouse pipelines, Warehouse SQL, native Power BI and the operational work that connects them.

Start with what you know

Python and Spark SQL, together

Use Python and Spark SQL together for Lakehouse Files and Delta Tables in the same dependency model.

Ordinary T-SQL

Keep ordinary SELECTs, without a proprietary modelling language or macros.

Native Power BI

Keep PBIP, TMDL and native Report definitions rather than converting to a Weaver-only format.

Desktop, Fabric Notebooks, or both

Build and operate the same project from desktop Python or the CLI, an attached Fabric Notebook, or both.

Install with pip

Install the open-source Python package with pip, without another Weaver server, orchestration service or software licence.

Existing Fabric services, compute and workspace permissions still apply. Lakehouse processing uses Fabric’s Spark runtime, not a separate Weaver orchestration service.

First Python pipeline Native document reference

Pipelines, dependencies and data quality

One dependency graph. Across Fabric.

Lakehouse

FilesPython Folder
Delta TablePython
Delta TableSpark SQL

Logical Shortcut
SQL endpoint readiness

Warehouse

TableT-SQL

Managed model source

Power BI

Semantic ModelRefresh

One managed Load/refresh graph orders the selected work across engines, with supported publication and endpoint-readiness barriers—not a separate pipeline joining engine jobs.

Logical Shortcuts and managed model sources supply cross-item edges. Build source items before Power BI items; a Report has no refresh of its own.

Connect Lakehouse and Warehouse Add a managed model source

One dependency graph across Fabric

Order selected managed Lakehouse work, Warehouse T-SQL and dependent Semantic Model refreshes in one DAG.

Generated Warehouse pipelines

A SELECT becomes a Table with generated staging, declared-key matching, row-change reconciliation and recorded results.

Managed Lakehouse pipelines

Materialise Files, Python and Spark SQL into managed Delta Tables without hand-building another orchestration project.

Dependency discovery

Python imports and supported T-SQL references supply dependencies; Spark SQL uses explicit declarations.

Incremental inserts, updates and deletes

Apply insert/update candidates and explicit delete keys under the declared policy, without rebuilding every target.

Per-consumer bookmarks

Each loadable Table or Folder keeps its own clean processing boundary, even when consumers share a source.

Tests and Assumptions

Compare expected and actual results or catch rule-breaking rows through supported Python, SQL and DAX validations.

Data-quality safeguards

Record rejected input and refuse proposed update/delete changes that exceed active stability thresholds.

Write a SELECT. Get the engineering around it.

You write

T-SQL query+ native metadata comment

Weaver supplies

Physical Table
Load procedure & staging
Declared-key reconciliation
Supported dependencies
Change statistics
Health evidence

Declare the key used to reconcile rows. Incremental source logic identifies changes and explicit deletes.

From a query to a managed Table

First Warehouse pipeline Load behaviour

Power BI, engineered for organisations

One modelling foundation. Different audiences. Consistent standards.

Native TMDL foundation+ shared policy

Operations model

Native variant + independent DAX checks

Operations ReportVerified model binding

Executive model

Native variant + independent DAX checks

Executive ReportVerified model binding

Compose native model sources, apply shared standards, validate calculations and deploy each Report against its intended model.

Native Semantic Model deployment

Deploy the PBIP/TMDL model you already author while preserving its native source files.

Organisation-wide modelling standards

Apply shared native TMDL policy across Semantic Models instead of repeating formats and conventions.

Built-in modelling annotations

Hide foreign keys, generate measure selectors and apply supported model rules through native TMDL annotations.

Custom Python annotations

Implement project-specific modelling conventions in trusted Python when native policy and built-ins are not enough.

Semantic Model composition

Reuse a native model foundation to produce audience variants without maintaining complete copies.

DAX validation and SQL reconciliation

Check DAX measures against independent expectations, including SQL calculations over managed Lakehouse or Warehouse sources.

Verified Report deployment

Deploy the same authored Report to different destinations, resolving and verifying its intended model and workspace binding.

Supported native model/Report deployment also works in an appropriately licensed Power BI service workspace, without Lakehouse/Warehouse work or a Weaver Catalogue.

Deploy a native model Power BI reference

An estate that knows what’s happening

Central Fabric Catalogue

Query installed definitions, signatures, metadata, dependencies and operational state in one Fabric Warehouse.

Unified Health

See current, stale, pending, failed or inconsistent work across the registered managed estate.

Logging and statistics

Inspect workflow history, Load counts, timings, row changes and recorded outcomes.

Fault-tolerant execution

Retain completed effects, record failures and blocked work, and optionally continue independent Load branches.

Selective execution

Select installed Load work by whole-name regex, deliberately add ancestors/descendants and preview the selection.

Controlled concurrency

Cap one invocation or tune per-resource limits while scheduling independent work in dependency order.

Sessions and workflows

Reuse execution context and automate sequences of the same operations used interactively.

Run and inspect an estate Operation boundaries

Visibility, included

Weaver comes with a Power BI dashboard over the catalogue. One command deploys it beside your estate.

Overview: installed items and Health. — Health, the Orchestration graph, when each run started and finished, a Gantt of each workflow, an ER diagram with a metadata browser, and a bus matrix for every semantic model.

Orchestration: one table's lineage, readiness and last outcome. — Health, the Orchestration graph, when each run started and finished, a Gantt of each workflow, an ER diagram with a metadata browser, and a bus matrix for every semantic model.

One command

weaver catalogue-dashboard deploys the semantic model and Report beside the catalogue, and brings them up to date on the next run.

Live over Direct Lake

The model reads the catalogue’s tables over Direct Lake, so each page shows your Weaver-managed estate as work is processed.

Free to tweak

It is an ordinary Power BI Report. Tweak it to fit your needs, or throw it away and build your own over the catalogue.

When your estate gets complicated

One project, multiple environments

Keep source files and logical identities while workspace configuration selects physical item and model destinations.

Mirror: develop without copying everything

Borrow installed Lakehouse/Warehouse data through Shortcuts and Views, then materialise selected changed or affected work locally.

Incremental Build

Reconcile changed source-data definitions and affected selected descendants, retaining certified unchanged source work.

Build previews

Inspect selected actions, physical targets and destructive effects through a read-only Build plan.

Controlled deployment bundles

Review and hand off frozen, destination-specific installation plans without replanning during Install.

Cross-engine publication and readiness

Order supported OneLake publication and SQL endpoint-readiness barriers before dependent cross-engine consumers.

Protect important data

Keep irreplaceable sources outside managed targets and use Build replacement guards for protected owned objects.

Develop against a large estate without copying it first.

Existing source estateSource-owned data
Borrowed development dataWarehouse Views · Lakehouse Shortcuts
Selected changed workMaterialised locally by Build

Keep unchanged objects borrowed while selected changed or affected work becomes local.

Mirror reconstructs the destination Catalogue and selected targets in the same workspace. Re-mirroring resets local work; it is not an in-place sync.

Develop using Mirror Scope and reset boundaries

Bundles are destination-specific. Build replacement guards do not protect data from Load, Wipe or deliberate resets.

From three objects to three thousand.

The scale benchmark records first-load and incremental processing separately. In the synthetic F64 benchmark, the 3,000-object estate’s first Load took about an hour; later measured incrementals were around 13 minutes. The first incremental day took about 19 minutes.

Built for scale →Get started →