How to Set Up dbt™ Fabric Integration with Paradime: Warehouse, Lakehouse & Target Configuration

Microsoft Fabric unifies data engineering and analytics under one roof—but the moment you wire dbt™ into the picture, a wave of questions hits: Do I point my dbt™ target at a Warehouse or a Lakehouse? Which adapter do I install? How do dev and prod stay isolated?

This guide cuts through the ambiguity. You will learn exactly how Fabric's Warehouse and Lakehouse map to dbt™ targets, how to configure connections in Paradime for both development (Code IDE) and production (Bolt Scheduler), and how to validate everything end-to-end.

What You Need to Know About dbt™ + Fabric

Warehouse vs Lakehouse Considerations

Microsoft Fabric offers two first-class storage workloads—Warehouse and Lakehouse—and each maps to a different dbt™ adapter with distinct capabilities.

Rule of thumb: If your team writes SQL transformations and needs reliable incremental loads, Warehouse + dbt-fabric is the production-grade choice. Use the Lakehouse when you need Spark/Python models or are landing raw files in OneLake first.

# Warehouse target (dbt-fabric)
my_project:
  target: dev
  outputs:
    dev:
      type: fabric
      driver: 'ODBC Driver 18 for SQL Server'
      server: your-workspace.fabric.microsoft.com
      port: 1433
      database: my_warehouse
      schema: dbt_dev
      authentication: ServicePrincipal
      tenant_id: "00000000-0000-0000-0000-000000001234"
      client_id: "00000000-0000-0000-0000-000000001234"
      client_secret: "S3cret!"

# Warehouse target (dbt-fabric)
my_project:
  target: dev
  outputs:
    dev:
      type: fabric
      driver: 'ODBC Driver 18 for SQL Server'
      server: your-workspace.fabric.microsoft.com
      port: 1433
      database: my_warehouse
      schema: dbt_dev
      authentication: ServicePrincipal
      tenant_id: "00000000-0000-0000-0000-000000001234"
      client_id: "00000000-0000-0000-0000-000000001234"
      client_secret: "S3cret!"

# Warehouse target (dbt-fabric)
my_project:
  target: dev
  outputs:
    dev:
      type: fabric
      driver: 'ODBC Driver 18 for SQL Server'
      server: your-workspace.fabric.microsoft.com
      port: 1433
      database: my_warehouse
      schema: dbt_dev
      authentication: ServicePrincipal
      tenant_id: "00000000-0000-0000-0000-000000001234"
      client_id: "00000000-0000-0000-0000-000000001234"
      client_secret: "S3cret!"

# Lakehouse target (dbt-fabricspark)
my_project:
  target: dev
  outputs:
    dev:
      type: fabricspark
      method: livy
      authentication: CLI
      endpoint: <https: api.fabric.microsoft.com="" v1="">
      workspaceid: "your-workspace-guid"
      lakehouseid: "your-lakehouse-guid"
      lakehouse: my_lakehouse
      schema

# Lakehouse target (dbt-fabricspark)
my_project:
  target: dev
  outputs:
    dev:
      type: fabricspark
      method: livy
      authentication: CLI
      endpoint: <https: api.fabric.microsoft.com="" v1="">
      workspaceid: "your-workspace-guid"
      lakehouseid: "your-lakehouse-guid"
      lakehouse: my_lakehouse
      schema

# Lakehouse target (dbt-fabricspark)
my_project:
  target: dev
  outputs:
    dev:
      type: fabricspark
      method: livy
      authentication: CLI
      endpoint: <https: api.fabric.microsoft.com="" v1="">
      workspaceid: "your-workspace-guid"
      lakehouseid: "your-lakehouse-guid"
      lakehouse: my_lakehouse
      schema

flowchart LR
    A[dbt™ Project] -->|type: fabric| B[dbt-fabric adapter]
    A -->|type: fabricspark| C[dbt-fabricspark adapter]
    B -->|ODBC / TDS| D[Fabric Warehouse]
    C -->|Livy API / Spark| E[Fabric Lakehouse]
    D --> F[OneLake - Delta Tables]

flowchart LR
    A[dbt™ Project] -->|type: fabric| B[dbt-fabric adapter]
    A -->|type: fabricspark| C[dbt-fabricspark adapter]
    B -->|ODBC / TDS| D[Fabric Warehouse]
    C -->|Livy API / Spark| E[Fabric Lakehouse]
    D --> F[OneLake - Delta Tables]

flowchart LR
    A[dbt™ Project] -->|type: fabric| B[dbt-fabric adapter]
    A -->|type: fabricspark| C[dbt-fabricspark adapter]
    B -->|ODBC / TDS| D[Fabric Warehouse]
    C -->|Livy API / Spark| E[Fabric Lakehouse]
    D --> F[OneLake - Delta Tables]

Figure 1 — How your dbt™ project's type setting routes to the correct Fabric workload and underlying OneLake storage.

How Paradime Manages Connections and Environments

Paradime separates connections by purpose:

Each slot stores its own profiles.yml fragment—server, database, schema, and credentials—so there is no risk of a developer accidentally writing to a production schema. Paradime injects the correct profile at runtime based on which environment triggers the dbt run.

flowchart TD
    subgraph Paradime
        IDE[Code IDE connection<br>target = dev]
        BOLT[Bolt Scheduler connection<br>target = prod]
        CI[TurboCI connection<br>target = ci]
    end
    IDE -->|developer runs| WH_DEV[Warehouse schema: dbt_jsmith]
    BOLT -->|scheduled runs| WH_PROD[Warehouse schema: analytics]
    CI -->|PR checks| WH_CI[Warehouse schema: dbt_ci]

flowchart TD
    subgraph Paradime
        IDE[Code IDE connection<br>target = dev]
        BOLT[Bolt Scheduler connection<br>target = prod]
        CI[TurboCI connection<br>target = ci]
    end
    IDE -->|developer runs| WH_DEV[Warehouse schema: dbt_jsmith]
    BOLT -->|scheduled runs| WH_PROD[Warehouse schema: analytics]
    CI -->|PR checks| WH_CI[Warehouse schema: dbt_ci]

flowchart TD
    subgraph Paradime
        IDE[Code IDE connection<br>target = dev]
        BOLT[Bolt Scheduler connection<br>target = prod]
        CI[TurboCI connection<br>target = ci]
    end
    IDE -->|developer runs| WH_DEV[Warehouse schema: dbt_jsmith]
    BOLT -->|scheduled runs| WH_PROD[Warehouse schema: analytics]
    CI -->|PR checks| WH_CI[Warehouse schema: dbt_ci]

Figure 2 — Paradime's three connection slots each target a different schema inside the same (or separate) Fabric Warehouse.

Prerequisites in Microsoft Fabric

Workspace + Capacity Requirements

Before Paradime (or any external tool) can reach your Fabric environment, you need:

1. An active Fabric capacity — A Fabric trial provides an F64 capacity. For persistent workloads, provision at least an F2 or higher SKU through Azure. If the capacity is paused, all ODBC/Livy connections will fail.

2. A Fabric workspace assigned to that capacity — Workspaces are the security and billing boundary. Create separate workspaces for dev and prod if your governance model requires it.

3. Capacity not throttled — Fabric throttles compute when cumulative CU consumption exceeds the SKU allowance. Monitor via the Microsoft Fabric Capacity Metrics app to avoid silent failures during dbt™ runs.

Create / Select Warehouse or Lakehouse

For Warehouse (recommended for dbt™):

1. Open your Fabric workspace → + New → Warehouse.

2. Name it (e.g., analytics_warehouse).

3. Note the Server hostname and Database name from the warehouse settings—you will need them for profiles.yml.

For Lakehouse:

1. Open your Fabric workspace → + New → Lakehouse.

2. Name it (e.g., raw_lakehouse).

3. Note the Workspace ID and Lakehouse ID (GUIDs) from the URL or settings pane.

⚠️ The Lakehouse SQL analytics endpoint is read-only. If you try to run dbt run against it via the dbt-fabric (ODBC) adapter, materializations that create or replace tables will fail. Use the dbt-fabricspark adapter for write operations against a Lakehouse.

Identity / Auth Setup and Permissions

dbt™ connects to Fabric through Microsoft Entra ID (formerly Azure AD). Two authentication paths dominate:

Minimum permissions checklist:

• The identity (user or SPN) must be added to the Fabric workspace with at least Member role (Microsoft docs).

• The identity needs CONNECT privileges on the warehouse database.

• For CREATE SCHEMA operations (common in dbt™ dev workflows), grant schema_authorization or ensure the identity is a workspace Admin.

• For the Lakehouse / Spark adapter, Service Principal auth is not yet supported by the Livy API—use Azure CLI auth.

Create the Fabric Connection in Paradime

Settings → Connections

1. Click Settings in the Paradime top menu bar.

2. In the left sidebar, click Connections.

3. Click Add New next to the Code IDE section.

4. Select Microsoft Fabric from the provider list.

5. Fill in the profile configuration (see next section).

6. Provide a dbt Profile Name that matches the profile: key in your dbt_project.yml.

7. Set the Target field to dev.

8. Click Test Connection to verify.

Repeat the process for the Scheduler (Bolt) section, changing the target to prod and the schema to your production schema.

Connection Parameters Explained

Below is a complete reference for the dbt-fabric adapter parameters you will enter in Paradime:

Tip: Validate your YAML before pasting it into Paradime. A single indentation error will cause a silent connection failure. Use yamlformatter.org for a quick check.

Credential Storage and Rotation

Paradime never stores credentials in its application database. All secrets—warehouse passwords, Service Principal client secrets, environment variable values—are encrypted at rest and in transit inside HashiCorp Vault running on Paradime's own AWS infrastructure.

Key security properties:

• Each company gets an isolated Vault path; no cross-tenant access is possible.

• Developer profiles.yml credentials are sandboxed inside each developer's own Kubernetes pod—no developer can read another's secrets.

• Queried data is held in memory only and erased on page refresh (Paradime is a data processor, not a data store).

• SOC 2 audited—report available at trust.paradime.io.

Rotation workflow: When your Entra ID Service Principal secret expires, update the credential in Paradime under Settings → Connections, edit the relevant connection, and replace the client_secret value. The change takes effect immediately for the next dbt™ run—no redeploy needed.

Firewall allowlisting: If your Fabric workspace enforces IP restrictions, add the Paradime egress IP for your data region:

Configure the Code IDE (Development)

Dev Target Strategy (Schemas / Namespaces)

The goal in development is isolation: every developer writes to their own schema so nobody overwrites another's work—or worse, production data.

Recommended pattern for Fabric:

Dev schema:   dbt_<username>        → dbt_jsmith
Prod schema:  <clean custom="" name="">   → analytics, staging, marketing
CI schema:    dbt_ci_pr_<number>    → dbt_ci_pr_142</number></clean></username>

Dev schema:   dbt_<username>        → dbt_jsmith
Prod schema:  <clean custom="" name="">   → analytics, staging, marketing
CI schema:    dbt_ci_pr_<number>    → dbt_ci_pr_142</number></clean></username>

Dev schema:   dbt_<username>        → dbt_jsmith
Prod schema:  <clean custom="" name="">   → analytics, staging, marketing
CI schema:    dbt_ci_pr_<number>    → dbt_ci_pr_142</number></clean></username>

Enforce this with a generate_schema_name macro override in macros/get_custom_schema.sql:

{% macro generate_schema_name(custom_schema_name, node) -%}
  {%- set default_schema = target.schema -%}
  {%- if target.name == 'prod' -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ custom_schema_name | trim }}
    {%- endif -%}
  {%- else -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ default_schema }}_{{ custom_schema_name | trim }}
    {%- endif -%}
  {%- endif -%}
{%- endmacro %}

{% macro generate_schema_name(custom_schema_name, node) -%}
  {%- set default_schema = target.schema -%}
  {%- if target.name == 'prod' -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ custom_schema_name | trim }}
    {%- endif -%}
  {%- else -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ default_schema }}_{{ custom_schema_name | trim }}
    {%- endif -%}
  {%- endif -%}
{%- endmacro %}

{% macro generate_schema_name(custom_schema_name, node) -%}
  {%- set default_schema = target.schema -%}
  {%- if target.name == 'prod' -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ custom_schema_name | trim }}
    {%- endif -%}
  {%- else -%}
    {%- if custom_schema_name is none -%}
      {{ default_schema }}
    {%- else -%}
      {{ default_schema }}_{{ custom_schema_name | trim }}
    {%- endif -%}
  {%- endif -%}
{%- endmacro %}

With this macro:

flowchart TD
    A["dbt run --target dev"] --> B{target.name == prod?}
    B -- No --> C["default_schema + '_' + custom_schema_name"]
    B -- Yes --> D["custom_schema_name only"]
    C --> E["dbt_jsmith_staging"]
    D --> F["staging"]

flowchart TD
    A["dbt run --target dev"] --> B{target.name == prod?}
    B -- No --> C["default_schema + '_' + custom_schema_name"]
    B -- Yes --> D["custom_schema_name only"]
    C --> E["dbt_jsmith_staging"]
    D --> F["staging"]

flowchart TD
    A["dbt run --target dev"] --> B{target.name == prod?}
    B -- No --> C["default_schema + '_' + custom_schema_name"]
    B -- Yes --> D["custom_schema_name only"]
    C --> E["dbt_jsmith_staging"]
    D --> F["staging"]

Figure 3 — The generate_schema_name macro routes dev builds into prefixed schemas and prod builds into clean schema names.

Model Build Patterns to Avoid Conflicts

1. Limit data in dev — Add a filter to expensive models so dev runs finish fast and consume fewer Fabric CUs:

2. Use dbt build instead of separate dbt run + dbt test — This runs each model and its tests in DAG order, catching failures earlier.

3. Avoid ephemeral materializations — The dbt-fabric adapter does not support nested CTEs (a T-SQL limitation). Ephemeral models that are referenced by other ephemeral models will error. Use view as the lightweight alternative.

4. Use tsql-utils instead of dbt-utils — Fabric's T-SQL dialect requires the tsql-utils package for cross-database macros like surrogate_key and date_spine.

Configure Bolt Scheduler (Production)

Prod Target Configuration

1. Navigate to Settings → Connections in Paradime.

2. Click Add New next to the Scheduler section.

3. Select Microsoft Fabric.

4. Enter the production profile:

5. Set Target to prod.

6. Click Test Connection.

Important: Always use a Service Principal for the Bolt Scheduler connection. Interactive authentication (CLI / browser) cannot run in headless mode. Make sure the SPN is a Member of the Fabric workspace and has CONNECT on the warehouse.

Schedule + Job Ownership

Create your first Bolt schedule:

1. Open Bolt from the Paradime home screen.

2. Click + New Schedule → + Create New Schedule.

3. Configure:

1. Click Save.

Figure 4 — End-to-end Bolt schedule execution flow, from cron trigger through Fabric materialization to Slack notification.

Bolt also supports YAML-based scheduling (configuration-as-code) so your schedule definitions can live alongside your dbt™ project in version control.

Validate with SQL Scratchpad

Once both connections are saved, validate them before you write a single model.

Run a Simple Query to Confirm Context

1. Open the Code IDE in Paradime.

2. Create a new Scratchpad tab (files land in the gitignored paradime_scratch/ folder).

3. Run a context-verification query:

4. Click Preview Data. Verify the values match your Code IDE connection settings.

Verify Create-Table Permissions

Next, confirm you can actually write objects:

-- Attempt to create and drop a validation table
CREATE TABLE dbt_validation_test (id INT);
DROP TABLE

-- Attempt to create and drop a validation table
CREATE TABLE dbt_validation_test (id INT);
DROP TABLE

-- Attempt to create and drop a validation table
CREATE TABLE dbt_validation_test (id INT);
DROP TABLE

If this succeeds, your identity has the required DDL permissions. If it fails with a permissions error, revisit the Identity / Auth Setup section above.

Bonus: Run dbt debug from the Code IDE terminal. It performs a comprehensive connection check—driver, authentication, database reachability, and schema permissions—in one shot.

Troubleshooting

Auth / Permission Issues

Workspace / Capacity Limitations

Target / Schema Naming Mismatches

Summary

Getting dbt™ Fabric integration right comes down to three decisions:

1. Warehouse vs Lakehouse — Choose dbt-fabric (type: fabric) for SQL-first transformations with full write support; choose dbt-fabricspark (type: fabricspark) only when you need Spark/Python models against a Lakehouse.

2. Auth method — Use Service Principal for production and CI (headless); use Entra ID password or CLI for interactive development.

3. Schema isolation — Override generate_schema_name so dev schemas are prefixed (dbt__) and prod schemas stay clean ().

With Paradime managing the connection plumbing—separate Code IDE, Bolt, and TurboCI slots backed by HashiCorp Vault—your team can focus on building models instead of debugging profiles.yml.

Next steps:

• Paradime Microsoft Fabric connection docs

• dbt-fabric adapter reference

• Microsoft Fabric Warehouse vs Lakehouse decision guide

• Creating Bolt Schedules in Paradime