dbt Jobs in Microsoft Fabric Explained

Navy Solv Systems title card reading 'dbt Jobs in Microsoft Fabric' with a blocks motif.

In Short: What dbt Jobs in Microsoft Fabric Are

A dbt job is a Fabric item that runs a dbt project inside your workspace. You author SQL models, tests and seeds in the browser, point the job at a warehouse, lakehouse or one of a few external databases, and run or schedule it from Fabric. There is nothing to install locally and no separate orchestrator to run.

Microsoft announced at FabCon Europe 2026 in Barcelona (29 September 2026) that dbt jobs are generally available. Alongside that, dbt logs now land in OneLake, and environment configuration can be carried through deployment pipelines with variable library support. Support for dbt Core v2, previously known as Fusion, is coming soon.

One thing to know before you start: at the time of writing, parts of Microsoft Learn still carry preview labels. The tenant setting is called "dbt jobs (preview)", and the dbt Job item is listed as preview in both the Git integration and deployment pipelines support lists. We expect the documentation to catch up, but check those pages before you sign off a production design. For the wider picture of Fabric's integration tools, see our guide to Data Factory in Microsoft Fabric.

How a dbt Job Runs

Fabric builds dbt jobs on dbt Core. Each job runs in a managed, versioned environment that Microsoft calls the dbt job runtime. New jobs use runtime 1.0 by default, which ships dbt Core 1.11 on Python 3.12.

The adapter decides where your SQL runs. Microsoft Learn currently lists five:

Fabric Data Warehouse - dbt-fabric 1.10.0, Microsoft Entra authentication
Fabric Lakehouse - dbt-fabricspark 1.12.2, Microsoft Entra authentication
Azure SQL Database - dbt-sqlserver 1.9.1, basic or service principal authentication
PostgreSQL - dbt-postgres 1.10.0, basic authentication
Snowflake - dbt-snowflake 1.11.5, Snowflake authentication

Microsoft says adapter and dbt versions are updated regularly, so treat those numbers as a snapshot rather than a contract.

The Warehouse adapter is the default and the most documented path. Your models compile to T-SQL and run on the warehouse engine. The Lakehouse adapter runs your models through Spark, so the behaviour and performance are Spark's - our introduction to Apache Spark explains what that means. If you are still deciding between the two targets, our lakehouse vs warehouse comparison is the place to start.

Inside the job you get a file explorer for models, seeds and YAML, a settings panel for the adapter, connection and schema, and an output panel with run logs. Advanced settings cover threads, fail fast and full refresh, and you can run selected models or use dbt selectors to include and exclude parts of the project.

The supported commands are `dbt build`, `dbt run`, `dbt seed`, `dbt test`, `dbt compile`, `dbt snapshot` and `dbt docs generate`. Docs generation writes the artefacts to the run output in OneLake, but Fabric does not yet render the documentation site itself. You download the files and serve them the usual way.

On cost, the job runs on your Fabric capacity, and Microsoft positions it as using your existing compute. The Data Factory pricing page we checked does not list a dedicated dbt meter, so measure a representative run in the Capacity Metrics app rather than assuming. Our guide to how Fabric measures usage explains what you will see there.

Where dbt Fits Next to Notebooks, Pipelines and Materialized Lake Views

Fabric now has several ways to transform data, and they overlap. This is how we divide the work:

Pipelines orchestrate. They move data, handle dependencies and failures, and call other items. A dbt job activity for pipelines was announced in preview in April 2026, so you can run dbt after an ingestion step rather than on a separate schedule. We have not seen it confirmed as generally available, and it is not yet in the Learn activity list we checked.
dbt jobs transform with SQL. They suit layered models with tests, documentation and lineage, written by people who think in SQL.
Notebooks handle what SQL cannot. Python logic, API calls, machine learning and heavy Spark work belong here.
Materialized lake views are declarative SQL inside the lakehouse. Fabric refreshes them in dependency order, applies data quality constraints and can refresh incrementally when change data feed is enabled on the sources. They are generally available.

The real choice is often between dbt and materialized lake views for lakehouse SQL. Materialized lake views are native, need no project structure and handle refresh for you. dbt brings a mature testing framework, macros, packages and a project that also runs against Snowflake or Azure SQL. If your team already knows dbt, or your medallion architecture spans more than one engine, dbt is usually the better fit. If you want a few governed silver and gold tables in one lakehouse, materialized lake views are simpler.

Git and CI/CD Considerations

There are two separate questions here: where the dbt project lives, and how the dbt job item moves between environments.

The project source. You can import a project or connect one from GitHub. Learn lists some limits that matter for teams with established repositories:

GitHub only, classic token only. Connecting from GitHub currently supports authentication with a classic personal access token only. Learn does not mention Azure DevOps as a project source for the dbt job itself.
`dbt_project.yml` must sit in the repository root. Monorepos with the project in a subfolder need restructuring or a dedicated repository.
5,000 files maximum on import. Larger projects need to be connected from GitHub or split.
No build caching. Each run compiles the project fresh, and artefacts from earlier runs are not available. Anything that relies on a previous manifest, such as state-based selection for slim CI, needs testing before you depend on it.

The item. The dbt Job item can be synced through Fabric Git integration and promoted through deployment pipelines, both still labelled preview on Learn as we write. The GA announcement adds variable library support, so connection and schema settings can change per stage without editing the job by hand. Microsoft has not yet published a detailed walkthrough of that pattern that we could find, so prove it in a test workspace first.

A personal access token tied to one developer's GitHub account is a weak point in a production setup. Decide who owns it, how it is rotated, and what happens when that person leaves.

When dbt Is the Right Choice

dbt jobs are a good fit when:

Your transformation logic is mostly SQL and you want tests, documentation and lineage to sit beside it
You already have a dbt project and want to retire a separate scheduler or virtual machine
Analysts and engineers share the work, and a reviewable SQL project suits both
You target more than one platform, such as a Fabric warehouse plus Snowflake or Azure SQL during a migration

They are a weaker fit when most of your logic is Python, when you need streaming or near real-time updates, or when a handful of materialized lake views would do the job with fewer moving parts. A project that relies on adapters outside the supported list, or on features of dbt Core v2, will also have to wait.

Migration Notes for dbt Core and dbt Cloud Teams

Moving an existing project into a Fabric dbt job is mostly a configuration exercise, but check these points before you commit:

Profiles. Fabric replaces `profiles.yml` with the dbt configurations page: adapter, connection and schema. Map each target you use today to a Fabric connection.
Versions. Runtime 1.0 runs dbt Core 1.11 with fixed adapter versions. If you pin a different version, run the project in a test workspace and compare the results.
Packages. `dbt deps` is not in Microsoft's list of supported commands. If your project depends on packages, confirm how they resolve before you migrate.
Authentication. The Warehouse and Lakehouse adapters use Microsoft Entra. SQL logins in your current profiles will not carry across for those targets.
Scheduling. Fabric's built-in schedule covers repeat, interval, start, end and time zone. More complex dependencies belong in a pipeline.
Docs and observability. Fabric offers lineage, compiled SQL and run results in the job, with logs in OneLake. Hosted documentation is not rendered in Fabric yet, so if your team relies on a hosted docs site, plan a replacement.
dbt Core v2. Microsoft lists support as coming soon with no date. If you have moved to the new engine elsewhere, stay where you are for now.

Teams on dbt Cloud should compare the developer experience as well as the run engine. Moving the runs into Fabric is the easy part. Replacing the editor, CI checks and docs your developers rely on is the work to plan.

How We Help

We help teams decide whether dbt belongs in their Fabric estate, and then make it production-ready. That means choosing between dbt and materialized lake views, setting up Git and deployment pipelines with variable libraries, migrating dbt Core or dbt Cloud projects, and sizing the capacity they run on. Our Microsoft Fabric consultants can review your current transformation layer and give you a clear plan. For everything else announced in Barcelona, see our FabCon Europe 2026 recap.

Sources and Further Reading

Frequently asked

A dbt job is a Fabric item that runs a dbt Core project inside your workspace. You author models, tests and seeds in the browser, connect the job to a target such as a Fabric warehouse or lakehouse, and run or schedule it from Fabric without installing dbt locally or running a separate orchestrator.

Yes. Microsoft announced general availability at FabCon Europe 2026 on 29 September 2026, along with dbt logs in OneLake and variable library support in deployment pipelines. At the time of writing some Microsoft Learn pages still carry preview labels, including the tenant setting and the Git integration and deployment pipeline support lists, so check them before signing off a production design.

Microsoft Learn lists five adapters: Fabric Data Warehouse (dbt-fabric), Fabric Lakehouse (dbt-fabricspark), Azure SQL Database (dbt-sqlserver), PostgreSQL (dbt-postgres) and Snowflake (dbt-snowflake). The default runtime, version 1.0, uses dbt Core 1.11 on Python 3.12.

Use materialized lake views for a small number of governed SQL tables inside one lakehouse, where native refresh and data quality constraints are enough. Use dbt when your team already knows it, when you want its testing framework, macros and packages, or when the same project must run against more than one platform.

Yes, from GitHub, with some limits. Authentication currently supports a classic personal access token only, dbt_project.yml must sit in the repository root, and imported projects are limited to 5,000 files. Each run compiles fresh with no build caching, so features that rely on previous run artefacts need testing.

Not yet. Microsoft lists support for dbt Core v2, previously known as Fusion, as coming soon and has not given a date. The current runtime uses dbt Core 1.11.

dbt jobs run on your Fabric capacity rather than a separate licence. The Data Factory pricing page we checked does not list a dedicated dbt meter, so measure a representative run in the Capacity Metrics app before you size or budget for it.