How do I reduce the number of tools around Microsoft Fabric?
Count the tools around Microsoft Fabric that exist only to hand data to the next tool. A typical stack has separate ingestion, transformation, orchestration, quality, and catalog tools, and the integration work between them usually costs more than the licences. Bruin covers ingestion, transformation, scheduling, and checks in one runtime against Microsoft Fabric, which removes the glue. The honest caveat: if one specialist tool is materially better at something you care about, that seam is worth keeping.
Command
bruin runDefined in
SQL + YAML
Works with
Microsoft Fabric + Bruin CLI
What you get
How to do it
- 1
List every tool touching Microsoft Fabric and what each one uniquely does.
- 2
Drop what you do not need yet: a catalog below roughly 200 tables, a dedicated orchestrator below a few dozen assets.
- 3
Consolidate ingestion, transformation, and checks into one project against Microsoft Fabric.
- 4
Keep any specialist tool that is genuinely better at something that matters.
- 5
Re-check the bill and the on-call load, which is the cost that never shows on an invoice.
How it works in code
/* @bruin
name: mart.orders
materialization:
type: table
strategy: merge
incremental_key: updated_at
@bruin */Run bruin run and Bruin moves only changed rows on Microsoft Fabric instead of rebuilding the table.
Worth knowing
On Microsoft Fabric, Direct Lake mode has specific table requirements; a table that falls back to DirectQuery silently gets slower Measure before and after: cost work done on intuition usually optimises the wrong job.
Other ways to do this
Bruin is not always the right answer. Here is where the alternatives are stronger.
| Option | When it is the better choice |
|---|---|
| Bruin | Practical levers for reducing tool count on Microsoft Fabric. |
| Native Microsoft Fabric cost tooling | Use it. Microsoft Fabric's own usage reporting is the right place to find out where the money actually goes before changing any tool. |
| dbt incremental models | The same incremental savings if dbt is already your transformation layer on Microsoft Fabric. No reason to migrate for this alone. |
| A cost-observability vendor | Worth it once spend is large enough that attribution across teams is the hard part rather than the optimisation itself. |
Common questions
How do I reduce the number of tools around Microsoft Fabric?
Drop tools you do not need yet, then consolidate ingestion, transformation, scheduling, and checks into one runtime against Microsoft Fabric.
Is a cheaper tool the way to cut Microsoft Fabric costs?
Usually not. Warehouse compute is normally the largest line and the most reducible. Licence savings matter, but far less than how often you rebuild tables and how much data each query reads.
What is the cheapest stack around Microsoft Fabric?
One with no per-seat and no per-row licence in it: open-source ingestion, open-source transformation, and your CI runner as the scheduler. That leaves warehouse compute as the only real bill.
Related use cases
Consolidate a Snowflake data stack
How do I reduce the number of tools around Snowflake?
Consolidation by warehouseConsolidate a BigQuery data stack
How do I reduce the number of tools around BigQuery?
Consolidation by warehouseConsolidate a Databricks data stack
How do I reduce the number of tools around Databricks?
Fewer tools, a smaller bill
Open source. No per-seat and no per-row fee, so the bill is warehouse compute.