Running Native dbt Jobs in Microsoft Fabric Data Factory

What Are Native dbt Jobs in Microsoft Fabric Data Factory?

Native dbt Jobs is a managed item type inside Microsoft Fabric Data Factory that runs dbt Core transformations without requiring an external dbt Cloud account, a self-hosted orchestration server, or a local dbt installation on a developer machine. The dbt project — models, tests, macros, and configuration — runs directly on Fabric-managed compute, scheduled and monitored the same way as Data Factory pipelines.

Before native dbt Jobs, running dbt transformations against Fabric Warehouse meant standing up dbt Cloud, a self-hosted Airflow instance, or a CI/CD runner specifically to invoke dbt run against the Fabric SQL endpoint. Native dbt Jobs removes that external dependency — the orchestration, compute, scheduling, and logging now live inside the same workspace as the warehouse itself.

Native dbt Jobs vs External dbt Orchestration

Teams running dbt against Fabric today typically use one of three external patterns: dbt Cloud, a self-hosted orchestrator (Airflow, Dagster) calling dbt CLI, or a CI/CD pipeline (GitHub Actions, Azure DevOps) triggering scheduled dbt runs. Native dbt Jobs is not a replacement for all of these — it is the right choice for specific scenarios.

The clearest advantage of native dbt Jobs is unified governance — dbt job runs appear in the same Fabric monitoring hub as pipelines, notebooks, and Spark jobs. Lineage between a dbt model and the Power BI report consuming it is visible without separate tooling. The clearest current limitation is the lack of build caching (see Section 10) — teams with large dbt projects relying on Slim CI patterns should evaluate this carefully before migrating off dbt Cloud.

Enabling Native dbt Jobs — Admin and Workspace Setup

Two separate permission levels control access to native dbt Jobs: a tenant-level admin toggle, and workspace-level role requirements for individual users.

Tenant Admin Setup

1. Open the Fabric Admin PortalA Fabric Tenant Administrator navigates to Settings → Admin Portal → Tenant settings.
2. Locate Data Factory settingsFind the Data Factory section of tenant settings, which groups all Data Factory-related preview toggles.
3. Enable “dbt jobs (preview)”Toggle the setting on for the entire organization, or scope it to specific security groups for a controlled rollout.

Workspace-Level Requirements

dbt Job Runtime v1.0 — Supported Adapters

The current dbt job runtime is version 1.0, built on dbt Core v1.9. It includes four supported adapters at launch, with a fifth — Fabric Lakehouse — on the near-term roadmap.

Creating Your First dbt Job in Fabric

1. Create a new dbt job itemIn your Fabric workspace, select New item → dbt job (preview). This creates a managed item that holds your dbt project configuration.
2. Connect your dbt project sourceLink the dbt job to a Git-connected repository containing your dbt project, or upload project files directly. Git integration follows the same Fabric Git connection pattern used for other workspace items.
3. Configure the target connectionSet the adapter and connection details for your target — Fabric Warehouse, Azure SQL Database, PostgreSQL, or Snowflake. Credentials are managed through Fabric connections, not stored in profiles.yml.
4. Define the dbt command to runSpecify which dbt command executes — dbt build, dbt run, dbt test, or a scoped selection like dbt run --select tag:daily.
5. Run and review resultsTrigger a manual run to validate the configuration. Review model execution status, test results, and any compilation errors in the run output before scheduling.

# Example dbt command configurations for a Fabric dbt job

# Full project build (models + tests + snapshots)
dbt build

# Run only models tagged for daily refresh
dbt run --select tag:daily

# Run and test a specific mart and its dependencies
dbt build --select +fct_orders

# Run tests only, skip model execution
dbt test --select tag:critical

Scheduling and Monitoring dbt Jobs

dbt job items support the same scheduling mechanism as other Fabric Data Factory items — time-based triggers configured directly on the item, or invocation from a parent pipeline using the Fabric pipeline activity for dbt jobs.

Standalone Scheduling

Configure a recurring schedule directly on the dbt job item — hourly, daily, weekly, or a custom cron-style expression. This is the simplest pattern for a dbt project that runs independently of other Fabric workloads.

Pipeline-Orchestrated Scheduling

For dbt runs that must execute after upstream ingestion completes, add a dbt job activity to a Fabric Data Factory pipeline. This allows the dbt job to run conditionally — only after a Copy Data activity or a Lakehouse load succeeds — rather than on a fixed independent schedule.

Monitoring for dbt job runs appears in the Fabric Monitoring Hub alongside pipeline runs, notebook runs, and Spark job runs — giving a single pane of glass for the entire orchestration layer rather than a separate dbt-specific monitoring surface.

Reviewing dbt Run Logs in OneLake

dbt job run logs — including model execution status, test results, and compiled SQL — are written to OneLake and accessible directly from the Fabric workspace. This means dbt run history is stored using the same governed, queryable storage layer as your data, rather than a separate logging system outside the Fabric security boundary.

What the Monitoring Interface Shows

CI/CD Integration for Native dbt Jobs

Native dbt Jobs integrate with Fabric’s standard Git-based deployment workflow rather than requiring a separate dbt-specific CI/CD pipeline. The dbt project lives in Git, and Fabric’s deployment pipelines move the dbt job item between Dev, Test, and Production workspaces alongside other Fabric artifacts.

Recommended Branching Pattern

main                  → Production workspace (scheduled runs)
release/*             → Test workspace (validation before promotion)
feature/*              → Dev workspace (individual development)

# Fabric deployment pipeline stages
Dev workspace  → [Deploy]  → Test workspace  → [Deploy]  → Production workspace

Each Fabric deployment stage can target a different Warehouse connection — meaning the same dbt project, with environment-specific connection configuration, runs against Dev, Test, and Production Fabric Warehouses without code changes between environments. This mirrors the dev/prod target pattern dbt Cloud and CLI users already rely on, but managed through Fabric’s native deployment pipelines instead of dbt-specific target configuration.

dbt Fusion Roadmap — What’s Coming to Fabric

At the December 2025 native dbt Jobs preview launch, Microsoft and dbt Labs announced a close collaboration, with dbt Fusion integration in Microsoft Fabric planned for calendar year 2026. dbt Fusion is dbt Labs’ next-generation execution engine, built on a Rust foundation for significantly faster compilation and execution compared to the Python-based dbt Core engine currently powering the v1.0 runtime.

For teams currently evaluating native dbt Jobs, the practical implication is that build caching and state-based Slim CI capabilities — currently the most significant gap versus dbt Cloud — are expected to improve as dbt Fusion integration progresses through 2026. This is also relevant to the dbt Core v2.0 alpha announced separately at Snowflake Summit 2026, which shares the same Rust-based foundation as Fusion. See dbt Best Practices for SQL Transformation for the dbt Core v2.0 details.

Current Limitations of Native dbt Jobs

FAQ — Native dbt Jobs in Microsoft Fabric Data Factory

Official Resources — Native dbt Jobs Documentation