TCO Analysis — Databricks vs Microsoft Fabric¶

Status: Authored 2026-04-30 Audience: Finance, platform engineering, and architecture teams building a business case for Databricks-to-Fabric migration. Scope: Total Cost of Ownership comparison covering compute, storage, BI licensing, reserved capacity, and operational overhead for both platforms.

1. Overview¶

This document provides a structured framework for comparing Databricks and Fabric costs. It is not a pricing calculator -- Azure pricing changes frequently and varies by region, contract type (EA, CSP, pay-as-you-go), and negotiated discounts. Instead, it provides the categories, formulas, and worked examples you need to build your own TCO model.

Pricing disclaimer: All figures are approximate, based on publicly available Azure pricing as of April 2026. Your actual costs depend on your Enterprise Agreement, region, reserved capacity commitments, and negotiated discounts. Always validate against your Azure pricing sheet.

2. Databricks cost structure¶

2.1 DBU pricing tiers¶

Databricks bills by Databricks Unit (DBU) -- a normalized unit of compute. Different workload types have different per-DBU rates:

2.2 Infrastructure costs (in addition to DBUs)¶

DBU charges do not include the underlying Azure VMs. Total Databricks cost = DBUs + VM cost + storage + networking:

2.3 Power BI costs on Databricks¶

When Databricks powers Power BI, you pay for both:

Key insight: On Databricks, the DBSQL warehouse must be running whenever a Power BI user opens a DirectQuery report. This creates a "BI tax" on Databricks compute that does not exist in Fabric.

2.4 Typical Databricks monthly cost (mid-size team)¶

3. Fabric cost structure¶

3.1 Fabric Capacity Units (CU)¶

Fabric uses a single billing meter: Capacity Units (CU). All workloads consume from the same pool:

3.2 What is included in Fabric CU¶

3.3 Smoothing -- 24-hour capacity averaging¶

Fabric does not charge per-second peak. Instead, CU consumption is averaged over a 24-hour rolling window. A workload that spikes to 64 CU for 1 hour but idles for 23 hours consumes an average of ~2.67 CU -- meaning an F4 capacity could handle it.

This is fundamentally different from Databricks, where you pay for every DBU consumed at peak. Smoothing benefits spiky workloads (batch jobs, report refreshes, ad-hoc queries) significantly.

3.4 OneLake storage costs¶

Key insight: OneLake shortcuts avoid data duplication. If your Delta tables already live in ADLS, shortcutting them into OneLake costs nothing for storage -- you keep paying ADLS rates.

3.5 Power BI on Fabric¶

On F64 and above, Power BI Premium features are included in the Fabric capacity:

For organizations on F64+, the Power BI Premium license ($4,995/month for P1) is eliminated -- a direct cost saving.

4. Worked example: mid-size analytics team¶

4.1 Scenario¶

• 10 data engineers, 5 data analysts, 50 BI consumers
• 200K DBU/month of batch ETL
• 50K DBU/month of interactive notebook development
• 30K DBU/month of DBSQL for Power BI
• 10 TB of Delta tables in ADLS
• 8 Power BI semantic models (4 Import, 4 DirectQuery to DBSQL)
• Power BI Premium P1 for enterprise deployment

4.2 Current Databricks cost¶

4.3 Fabric cost (full migration)¶

4.4 Fabric cost (hybrid -- Databricks keeps ML/heavy ETL)¶

4.5 Savings summary¶

Caveat: The full migration assumes all Spark workloads fit within F128 capacity with smoothing. Validate with a Fabric capacity trial before committing. Photon-dependent workloads may require larger capacity or may not perform equivalently.

5. Cost optimization strategies¶

5.1 Fabric-specific¶

5.2 Databricks-specific (for hybrid)¶

6. Hidden costs to factor in¶

6.1 Migration costs (one-time)¶

6.2 Ongoing operational costs¶

7. Building your own TCO model¶

Step 1: Inventory current Databricks spend¶

-- Run in Databricks SQL to get DBU consumption by SKU
SELECT
    sku_name,
    usage_date,
    SUM(usage_quantity) AS total_dbus,
    SUM(usage_quantity * list_price) AS estimated_cost
FROM system.billing.usage
WHERE usage_date >= DATEADD(MONTH, -3, CURRENT_DATE())
GROUP BY sku_name, usage_date
ORDER BY usage_date, sku_name

Step 2: Map to Fabric capacity¶

Use Microsoft's Fabric Capacity Metrics app (available in AppSource) during a trial to measure actual CU consumption for representative workloads. Key metrics:

• CU seconds per Spark job -- compare to DBU consumption for the same job
• CU seconds per SQL query -- compare to DBSQL DBU for the same query
• Background CU -- Power BI cache, metadata operations

Step 3: Apply smoothing¶

Calculate your 24-hour average CU consumption, not peak. If your batch jobs run for 4 hours at 128 CU and idle for 20 hours, the smoothed consumption is:

Smoothed CU = (128 CU * 4 hours + 0 CU * 20 hours) / 24 hours = 21.3 CU

An F32 capacity would handle this, not F128.

Step 4: Add Power BI savings¶

If you are currently paying for Power BI Premium, add that to the savings column if moving to F64+ (where Premium is included).

Step 5: Factor in reserved capacity¶

Apply the reserved capacity discount to your base capacity SKU. Use PAYG for burst/overage.

8. When the math does not favor Fabric¶

• GPU-heavy workloads: Databricks GPU cluster costs are high, but Fabric has no GPU Spark option. Azure ML compute adds a separate billing line.
• Photon-dependent queries: If Photon makes a 4-hour job run in 1 hour, the DBU savings from Photon may be cheaper than running the same job on Fabric Spark for 3-4 hours at CU rates.
• Very small workloads: For teams spending <\(500/month on Databricks, the minimum Fabric capacity (F2 at ~\)260/month) may not save money, especially if Power BI Premium is not needed.
• Multi-cloud: If you need the same workloads on AWS and Azure, maintaining Fabric adds a second platform rather than consolidating.

Related¶

• Why Fabric over Databricks -- strategic analysis
• Benchmarks -- performance comparisons
• Best Practices -- capacity planning guidance
• Feature Mapping -- feature-by-feature equivalents
• Parent guide: 5-phase migration
• Microsoft Fabric pricing: https://azure.microsoft.com/pricing/details/microsoft-fabric/
• Databricks pricing: https://www.databricks.com/product/pricing

Maintainers: csa-inabox core team Source finding: CSA-0083 (HIGH, XL) -- approved via AQ-0010 ballot B6 Last updated: 2026-04-30