Databricks vs Snowflake vs Microsoft Fabric: which one fits, and what it costs to change your mind

Databricks, Snowflake and Microsoft Fabric all want to be the one place your data, reports and AI agents live. They bill in different ways and put the security boundary in different spots. Choose on where your people already work and how you want to be billed, then run a two-week proof on your own data before anyone signs.

The licence or creditdefinitionSnowflake's meter for compute. An X-Small Gen1 warehouse burns one credit an hour, and every size up doubles that, so oversizing shows up fast. price is the part everyone compares, and it's the least reliable number in the room. Databricks and Snowflake both say their price depends on edition or tier, cloud and region. Fabric publishes a price per capacity unitdefinitionFabric's measure of compute. An F64 has 64 of them, and every workspace on it shares that pool, so one heavy job can slow the rest., but what you actually pay depends on how well the capacity fits your peaks. Two platforms that look the same on a slide can end up far apart on the bill.

The expensive part is leaving. Pipelines, security rules, notebooks and semantic models all get written in one platform's dialect. On Hacker News, one commenter described their employer moving petabytes from Snowflake to Databricks as wildly disruptive. That's one person's account, but it matches the shape of any move: every job, every grant and every report gets touched again.

Most of the work sits in the first two steps. A company whose finance team lives in Excel and Power BI and has no Spark engineers will find Fabric the easiest to adopt. A company that trains its own models and already runs on AWS will usually have a shortlist of Databricks and Snowflake. Fabric is a weaker fit there, because it runs on Azure, even though its shortcuts can read S3.

The compute location matters more than the brochures suggest. With Databricks classic compute, the virtual machines show up on your own cloud bill and inside your own network. Security teams can see them, and finance can commit cloud spend against them. With Snowflake and Fabric, you trade that visibility for less to run. Databricks also offers serverless compute, which runs in Databricks' own account, so you can pick per workload.

Fabric's capacity model is the one that surprises people. You buy a size, from F2 up to F8192, and every workspace on that capacity shares it. Short spikes are absorbed by smoothing, and that's a strength. A long overload is different, because the whole capacity slows down, including the CFO's report. Snowflake and Databricks isolate that kind of problem by giving each team its own warehouse or cluster.

None of the three publishes one price that fits everyone. Databricks says DBUdefinitionDatabricks Unit, the meter Databricks bills by the second. What one costs depends on the compute type, tier, cloud and region, so two teams can pay different rates. rates vary by cloud, region, tier and compute type, and classic compute adds your cloud provider's VM charges on top. Snowflake says the edition sets the unit cost of a credit and of storage, and region and contract type change it again. Fabric is the most transparent: Microsoft's public price list shows $0.18 per capacity unit hour, pay as you go, in East US. A one or three-year reservation saves about 41%, by Microsoft's own pricing page.

After the unit price, four things move the number most. Idle time is the first. Snowflake suspends idle warehouses by default, and Databricks clusters can auto-terminate after a set number of minutes. A Fabric capacity bills by the second while it's running, busy or not, unless someone pauses it. Sizing comes second. Each step up a Snowflake warehouse size doubles the credits per hour, and an oversized Fabric capacity is money spent on headroom.

Third is AI usage, which now bills on its own meter. Databricks Genie moved to pay-as-you-go on 8 July 2026 with 150 free DBUs a month, which Databricks puts at about $10.50 in US East. Genie One and Genie Agents are free for users through 31 January 2027, but service principals are billed. Fourth is the people who run it. Fabric needs someone watching capacity. Databricks needs someone who understands cluster and compute policies, and Snowflake needs someone who owns warehouse sizing.

That last table is the one finance should read. Snowflake's own docs say resource monitors can't track serverless features or AI services, and budgets alert unless you add a custom action. Databricks says its budgets aren't a way to guarantee an absolute spend cap. We didn't find one switch that caps the whole bill on any of the three. You get closest with warehouse monitors in Snowflake, per-cluster limits in Databricks and pausing in Fabric, and someone still has to read the bill.

The Power BI Premium change is the one that forces some companies into this decision. Microsoft no longer sells new P SKUs, and outside sovereign clouds each one retires at the end of its agreement term. After that there's a 30-day grace period. Interactive work is throttled from day 31, and from day 91 every operation is rejected. Migration isn't automatic. Someone has to buy an F SKU and move the workspaces, and a P1 maps to an F64.

That deadline creates a natural moment to ask the bigger question. If you're moving to F SKUs anyway, you're already paying for Fabric capacity. Using it for pipelines and a lakehouse can look free. It isn't, because those jobs share the same capacity as your reports. Size for both before you assume the existing F64 covers it.

With open tables, the catalog that owns the data decides how much the others can do. Databricks says external engines can read and write managed IcebergdefinitionAn open table format from the Apache project. Spark, Trino, Snowflake and others can all read the same Iceberg table, so nobody has to copy it. tables through its Iceberg REST endpoint, but Delta tables exposed as Iceberg are read-only to them. Snowflake's own Iceberg v3 tables can't yet be written by outside engines through Horizon Catalog. Fabric turns Delta tables in OneLake into Iceberg v2 metadata, but only for tables under 5,000 commits, and not in tenants or workspaces with private links.

One practitioner on Hacker News sat through months of sales calls with all three vendors. Afterwards, they were leaning toward plain Iceberg on managed object storage and none of the three, though they said they might still start with Snowflake. Most companies won't go that far, but the point holds. Keep your important tables in an open format in storage you control, and the platform choice becomes much easier to change later.

Fabric is the simplest to reason about here, and the least flexible. Every request is authenticated by Microsoft Entra ID, so Conditional Access and MFA apply to it. Conditional Access needs an Entra ID P1 licence. If your workforce identity runs on Okta, people still reach Fabric through Entra ID. Service principals only work after a tenant admin turns them on. A workspace identity, which is a service principal Fabric manages for you, avoids storing secrets for pipelines.

One Fabric rule catches people out. OneLake security roles, including row and column security, apply to users with the Viewer role or read permission on an item. Admins, Members and Contributors already read and write everything in the workspace, so the row rules don't touch them. Put engineers who build things in separate workspaces from the data they shouldn't see.

Databricks and Snowflake both take SAML 2.0 or OIDC from Okta, Entra ID and others, and both support SCIM. On Azure Databricks, automatic identity management pulls users, groups and service principals straight from Entra ID, and it's on by default for accounts created after 1 August 2025. For jobs and scripts, Databricks prefers OAuth machine-to-machine. The service principal's secret can stay valid for up to two years and gets swapped for one-hour tokens, so keep that secret in a vault and rotate it.

Snowflake has spent 2026 closing the password door. Its rollout schedule has human users who sign in with a password needing a second factor, and service users can't use passwords at all. Reader accounts, trial accounts and Snowflake Postgres are excluded. Machines move to key pairs, programmatic access tokens, which expire after 15 days by default, or workload identity federation with AWS, Entra ID or Google Cloud. Check the BI servers and ETL tools first, since that's where old drivers and stored passwords usually turn up.

Switching later means reworking jobs, grants and reports, even when the data moves easily. Security rules don't carry over on their own. Unity Catalog grants, Snowflake masking policies and OneLake roles are written in different models, so each one has to be redesigned and retested. That's why the open-table choice in chapter 5 matters more than which logo goes on the contract.

We build on Databricks, Snowflake and Fabric, so we don't need you to pick one before we start. We'll script your hardest workloads and run the proof on your own data. Then you get a three-year cost view that includes the team. See our Databricks, Snowflake and Microsoft Fabric pages, hire engineers for Databricks, or start with an assessment.