Weaver is under active development

Weaver

Fabric, declared.

One repository for your whole Microsoft Fabric data estate.

Declare Lakehouse ingestion, Spark transformations, Warehouse models and cross-item dependencies together. Weaver builds and orchestrates them incrementally, with metadata, lineage and operational controls built in.

Declaration → estate → orchestrationone control plane
01 / CodeWeaver repository
Lakehouse/ Raw/ Files/ Sales__Export.py Sales__Customer.py Sales.Clean.sql ML/ Files/ Sales__Prediction.py Warehouse/ Reporting/ Sales.Forecast.sql
02 / MaterialisedFabric workspace
Raw LakehouseFiles + Delta
Files/Sales/ExportΔ Sales.CustomerΔ Sales.Clean
ML LakehouseFiles + Delta
Δ Sales.Prediction
Reporting WarehouseT-SQL
view Sales.Forecast
03 / OrchestratedCross-item DAG
Raw / Python01 · Export
Raw / Delta02 · Customer
Raw / Spark03 · Clean
ML / Python04 · Prediction
Reporting / T-SQL05 · Forecast
01 → 02 Every document becomes its Fabric artefact.02 → 03 Those artefacts form one branching graph.
declaration → materialisation → orchestration

01 / The declared estate

Your Fabric estate belongs in source control.

A Weaver repository describes the logical structure of the whole estate. Each document has an owner, every owner is a Fabric item, and the directory makes that architecture visible.

The directory is the architecture.
estate/
Lakehouse/
├── Raw/
│   ├── Files/
│   │   └── Sales__Export.py
│   ├── Sales__Customer.py
│   └── Sales.Clean.sql
├── ML/
│   └── Sales__Prediction.py
└── _weaver/

Warehouse/
└── Reporting/
    ├── alias.yml
    ├── Sales.Customer.sql
    └── Sales.Forecast.sql

Logical identity. Physical choice.

The repository describes what the estate is. Workspace configuration decides where it is installed.

Bind the same logical Lakehouses and Warehouses to different development, test or production workspaces without changing their authored identity.

01Organise documents beneath the Fabric items that own them.
02Resolve typed, explicit bindings for each physical destination.
03Materialise the estate from one inspectable declaration.

02 / Cross-item orchestration

Many items. One graph.

Dependencies do not stop at item boundaries. Neither does Weaver. Lakehouse Python, Delta, Spark SQL and Warehouse T-SQL take their place in the same dependency graph.

Raw Lakehouse

Sales.ExportPython ingestion
Sales.CustomerDelta table
Sales.CleanSpark SQL

ML Lakehouse

Sales.PredictionPython + Delta

Reporting Warehouse

Sales.CustomerT-SQL table
Sales.ForecastT-SQL view

Item boundaries are visible. They are not execution boundaries.

03 / End-to-end engineering

Not just the transform layer.

Weaver is designed for the complete path from source ingestion to analytics publication—without splitting one engineering system into disconnected platforms.

{ }API / filessources
PyPythoningestion
F/Lakehousefiles
ΔDeltatables
SpSpark SQLtransform
SQLWarehousemodels
Analyticspublication

Python, Spark and T-SQL are parts of one pipeline—not separate platforms.

04 / Production engineering

Production engineering without the platform project.

The structural and operational foundations are consequences of the architecture—not a collection of bolt-on features.

What Weaver plans is what Weaver executes.

Weaver interprets the repository, bindings, target state and dependencies once. It compiles them into an inspectable build plan containing the exact actions and execution order.

01Incremental builds from deterministic plans
02Dependency-safe execution and failure recovery
03Central catalogue, metadata and lineage
04Target reconciliation and installation history
build-plan.ymlinspectable
selection:
  new:
    - Lakehouse/ML/Sales.Prediction
  changed:
    - Warehouse/Reporting/Sales.Forecast

actions:
  - reconcile catalogue
  - build Sales.Prediction
  - rebuild Sales.Forecast
  - publish metadata
  - certify Registry

05 / Data science

Data science is part of the pipeline.

Train or score models in a Lakehouse, declare prediction outputs as Weaver documents, and connect them to downstream Warehouse models through the same graph.

No separate ML side pipeline.
WarehouseTraining dataCurated features
Lakehouse / PythonModel executionTrain or score
Lakehouse / DeltaPredictionsDeclared output
Warehouse / T-SQLReporting modelPublished analytics
Build, repository, Workspace and catalogue foundations End-to-end load orchestration — active development Additional ML workflows — planned

Straight answers

Questions

Weaver has a deliberately specific place in the modern data stack.

How is Weaver different from Fivetran, dbt, Prefect and similar tools?

Those tools specialise in important concerns across many technologies. Weaver specialises in the whole engineering lifecycle on Microsoft Fabric.

FivetraningestiondbtSQL transformationPrefectgeneral-purpose orchestrationWeaverthe declared Fabric data estate

Weaver can also coordinate with tools already present in an estate; it does not require every team to replace them.

How does Weaver differ from dbt?

dbt is an excellent SQL transformation framework. Weaver treats transformation as one stage in a larger Fabric lifecycle that also includes Lakehouse Python, files, Delta, Spark SQL, multiple Lakehouses and Warehouses, cross-item dependencies, physical bindings, ingestion and execution metadata.

Not just the transform layer.

How does Weaver differ from Prefect?

Prefect is a general-purpose orchestration platform. In Weaver, the dependency graph comes from the same declarations that define the data estate—there is no second orchestration model to keep aligned.

declare objects → declare dependencies → build the DAG → execute

Why focus only on Microsoft Fabric?

Because first-class support matters. Weaver treats Lakehouses, Warehouses, Delta, Spark, T-SQL, Fabric Environments, OneLake, workspace bindings and Fabric execution as native architectural elements—not a lowest-common-denominator abstraction.

How hard is it to get started?

Install Weaver into a Fabric Environment or local Python environment, begin with a Weaver repository, and bind its logical items to your workspace.

pip install weaverstack
pip install "weaverstack[cli]"  # optional desktop CLI
Can I use Weaver directly inside Fabric?

Yes. The ordinary product path runs Weaver inside a Fabric Environment-backed session. Weaver reads the uploaded repository, prepares target and catalogue state, generates the build bundle and installs it in that same session.

from weaver import build_uploaded_item_repository

result = build_uploaded_item_repository(
    repository_root=repository_root,
    bindings=bindings,
    environment=environment,
    control_lakehouse=control_lakehouse,
)

The supporting values are resolved Weaver objects.

Can I use Weaver from my desktop?

Yes. The CLI installs Weaver, initialises the control plane, validates and pushes the repository, and invokes builds for selected physical targets.

weaver install --workspace-config workspace.yml
weaver initialise --workspace-config workspace.yml --exists-ok
weaver push ./estate --workspace-config workspace.yml
weaver build --workspace-config workspace.yml \
  --bind Lakehouses/Sales_Dev \
  --bind Warehouses/Reporting_Dev
Is Weaver desktop software or a cloud service?

Your choice. Weaver is an open-source Python runtime and optional CLI—not a hosted SaaS control plane. It can run inside Fabric, from the desktop CLI, against the local Lakehouse emulator, from CI/CD, and through notebooks and Fabric Environments.

What does Weaver cost?

Weaver is free and open source. There are no Weaver licence fees, hosted tiers, per-user charges or Weaver usage limits. Microsoft Fabric remains a paid service, and Weaver workloads use the Fabric capacity and infrastructure you control.

Is Weaver ready for production?

Weaver is under active development. The build, repository, Workspace and catalogue foundations are already substantial, while end-to-end load orchestration and additional Fabric capabilities are evolving. Follow the repository, current design, roadmap and issues.

Declare your Fabric estate.

Build Lakehouse ingestion, Warehouse models and cross-item workflows as one coherent engineering system.

Weaver is under active development. Follow the project and help shape the platform.