Fabric and Azure
How to Use dbt Cloud with Microsoft Fabric
dbt Cloud transforms data inside your warehouse with version-controlled SQL models. What a model looks like, how tests work, and connecting it to Fabric.
Austin Levine
·
Updated
dbt Cloud transforms data that already sits in a warehouse. You write SQL models that reference each other, dbt Cloud compiles them into the right run order, executes them against the warehouse, and runs tests against the results. It does not move data into the warehouse; that is a separate ingestion step, done by a tool such as Fivetran or a Fabric Data Factory pipeline.
What a dbt model looks like
A dbt model is a SQL file that defines one table or view. Models reference each other with the ref() function instead of hardcoding table names, so dbt can work out the dependency order automatically:
-- models/marts/fct_orders.sql
with orders as (
select * from {{ ref('stg_orders') }}
),
customers as (
select * from {{ ref('stg_customers') }}
)
select
orders.order_id,
orders.order_date,
orders.order_total,
customers.customer_id,
customers.customer_name
from orders
left join customers on orders.customer_id = customers.customer_idRunning dbt run builds every model in the project in dependency order: stg_orders and stg_customers first, then fct_orders once both are available.
Testing a model
Tests are defined next to the model in a YAML file, not in code:
## models/marts/schema.yml
models:
- name: fct_orders
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- relationships:
to: ref('stg_customers')
field: customer_iddbt test runs every defined test and fails the run if a column that should be unique has duplicates, a required column has nulls, or a foreign key points at a row that does not exist. Tests run against the warehouse's real data, not a mock, so they catch upstream data problems as well as SQL bugs.
The dbt Cloud workflow
dbt Cloud adds a hosted layer on top of open-source dbt: a browser IDE or CLI for development, a job scheduler, and environments for development and production.
Develop. Write and preview models against the warehouse from the dbt Cloud IDE or a local CLI connected to a development schema.
Version control. Every project is backed by a git repository. Changes go through a branch and a pull request, the same as application code.
Run and test on a schedule or on merge. A dbt Cloud job runs
dbt build(which runs models and their tests together) on a schedule, or automatically when a pull request merges to the main branch.Deploy to production. A successful run in the production environment is what downstream tools, including Power BI, should read from.
Connecting dbt Cloud to Microsoft Fabric
dbt connects to Microsoft Fabric Data Warehouse through the dbt-fabric adapter, maintained by Microsoft. The workflow is the same as any other warehouse: models compile to SQL, and dbt Cloud runs them against the Fabric Warehouse's SQL endpoint. The resulting tables sit in OneLake, Fabric's shared storage layer, which Fabric's other workloads use too.
From there, Power BI connects to the transformed tables the same way it would connect to any Fabric Warehouse table, including through Direct Lake mode. For the equivalent setup against Snowflake, see our guide to connecting Power BI to Snowflake. If the data needs to reach the warehouse before dbt can transform it, see our Data Factory showdown for how that ingestion step works in Fabric versus Azure Data Factory.
What dbt Cloud does not do
dbt Cloud transforms data already in a warehouse. It does not extract data from source systems, and it does not build the Power BI semantic model, DAX measures or report layout downstream of the tables it produces. Keeping transformation logic in version-controlled SQL models, rather than in Power Query steps inside each report, means the same tested table can feed more than one report without repeating the logic. See our guide to data modeling in Power BI for what belongs in the model once dbt's output reaches it.
Sources
Set up dbt for Fabric Data Warehouse - Microsoft Learn
About dbt tests - dbt Labs
dbt Cloud transforms data that already sits in a warehouse. You write SQL models that reference each other, dbt Cloud compiles them into the right run order, executes them against the warehouse, and runs tests against the results. It does not move data into the warehouse; that is a separate ingestion step, done by a tool such as Fivetran or a Fabric Data Factory pipeline.
What a dbt model looks like
A dbt model is a SQL file that defines one table or view. Models reference each other with the ref() function instead of hardcoding table names, so dbt can work out the dependency order automatically:
-- models/marts/fct_orders.sql
with orders as (
select * from {{ ref('stg_orders') }}
),
customers as (
select * from {{ ref('stg_customers') }}
)
select
orders.order_id,
orders.order_date,
orders.order_total,
customers.customer_id,
customers.customer_name
from orders
left join customers on orders.customer_id = customers.customer_idRunning dbt run builds every model in the project in dependency order: stg_orders and stg_customers first, then fct_orders once both are available.
Testing a model
Tests are defined next to the model in a YAML file, not in code:
## models/marts/schema.yml
models:
- name: fct_orders
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- relationships:
to: ref('stg_customers')
field: customer_iddbt test runs every defined test and fails the run if a column that should be unique has duplicates, a required column has nulls, or a foreign key points at a row that does not exist. Tests run against the warehouse's real data, not a mock, so they catch upstream data problems as well as SQL bugs.
The dbt Cloud workflow
dbt Cloud adds a hosted layer on top of open-source dbt: a browser IDE or CLI for development, a job scheduler, and environments for development and production.
Develop. Write and preview models against the warehouse from the dbt Cloud IDE or a local CLI connected to a development schema.
Version control. Every project is backed by a git repository. Changes go through a branch and a pull request, the same as application code.
Run and test on a schedule or on merge. A dbt Cloud job runs
dbt build(which runs models and their tests together) on a schedule, or automatically when a pull request merges to the main branch.Deploy to production. A successful run in the production environment is what downstream tools, including Power BI, should read from.
Connecting dbt Cloud to Microsoft Fabric
dbt connects to Microsoft Fabric Data Warehouse through the dbt-fabric adapter, maintained by Microsoft. The workflow is the same as any other warehouse: models compile to SQL, and dbt Cloud runs them against the Fabric Warehouse's SQL endpoint. The resulting tables sit in OneLake, Fabric's shared storage layer, which Fabric's other workloads use too.
From there, Power BI connects to the transformed tables the same way it would connect to any Fabric Warehouse table, including through Direct Lake mode. For the equivalent setup against Snowflake, see our guide to connecting Power BI to Snowflake. If the data needs to reach the warehouse before dbt can transform it, see our Data Factory showdown for how that ingestion step works in Fabric versus Azure Data Factory.
What dbt Cloud does not do
dbt Cloud transforms data already in a warehouse. It does not extract data from source systems, and it does not build the Power BI semantic model, DAX measures or report layout downstream of the tables it produces. Keeping transformation logic in version-controlled SQL models, rather than in Power Query steps inside each report, means the same tested table can feed more than one report without repeating the logic. See our guide to data modeling in Power BI for what belongs in the model once dbt's output reaches it.
Sources
Set up dbt for Fabric Data Warehouse - Microsoft Learn
About dbt tests - dbt Labs
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany
Free tools
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany
Free tools
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany
