Microsoft Fabric vs Snowflake
Both separate storage from compute and bill on an abstracted unit instead of raw VM pricing. The real differences are storage openness, how compute is sized, and how tightly each ties into its BI layer.
At a glance
| Dimension | Fabric | Snowflake |
|---|---|---|
| Storage format | Delta Lake (open Parquet) on OneLake | Proprietary micro-partitions natively; Iceberg tables as a newer, separate option |
| Compute model | One shared capacity (CUs) across every engine | Independently sized virtual warehouses (XS–4XL) per workload |
| Primary language | Spark/Python-first, plus a T-SQL Warehouse engine | SQL-first; Snowpark bridges to Python/Java/Scala |
| Catalog / governance | OneLake security (RLS/CLS/TLS on the lakehouse) | Role hierarchy with inherited grants |
| BI integration | Power BI Direct Lake (same tenant, no import) | Strong partner BI connector ecosystem, no zero-copy semantic model |
| Billing unit | Capacity Units — one shared, smoothed pool per capacity | Credits — metered per virtual warehouse, per second |
| Deployment scope | Microsoft Fabric SaaS (Azure-hosted) | Multi-cloud (Azure, AWS, GCP) |
Where they're actually similar
- Both separate storage from compute. Neither ties you to a fixed cluster running 24/7 for occasional queries — Snowflake suspends idle warehouses, Fabric's capacity model smooths usage across workloads rather than per-warehouse.
- Both abstract away infrastructure sizing. You pick a warehouse size or a capacity SKU, not a VM type or core count. Neither requires you to manage the underlying cluster.
- Both version their tables. Snowflake's Time Travel and Delta Lake's transaction log both let you query or restore a prior table state — see VACUUM & retention for how Fabric governs how far back that window goes.
Where they genuinely differ
- Storage openness. A native Snowflake table lives in a proprietary format you can only query through Snowflake. A Fabric lakehouse table is Delta Parquet on OneLake from the start — readable by Spark, the SQL endpoint, or an external engine via a shortcut in the other direction, with no export step.
- Compute sizing model. Snowflake warehouses are sized and billed independently per workload (XS through 4XL). Fabric pools every workload — Spark, Warehouse, Direct Lake — against one Capacity Unit budget you size once.
- Engine breadth. Snowflake is a SQL engine first, with Snowpark bridging to Python/Spark-style workloads. Fabric ships Spark notebooks, a T-SQL warehouse, and KQL side by side over the same OneLake storage — pick the engine per workload rather than per platform.
- BI integration depth. Fabric's Direct Lake reads OneLake tables straight into a Power BI semantic model with no import step. Snowflake has a mature partner BI ecosystem, but every connection is external.
Migrating from Snowflake to Fabric
If you're moving an existing estate rather than choosing greenfield, the step-by-step conversion — DDL translation, task graphs, role mapping, and the VARIANT decision — is in the migration playbook.
Read the migration playbookFAQ
Is Snowflake data locked into a proprietary format?
Native Snowflake tables use proprietary micro-partitions you can't read outside Snowflake directly. Snowflake's newer Iceberg table support is an open-format escape hatch, but it's a separate table type you opt into, not the default. Fabric's OneLake is Delta Parquet natively — every table is already in an open format any engine can read.
Does Fabric have Snowflake-style Time Travel?
Yes, via Delta Lake's own history — VERSION AS OF queries a prior table version, the same underlying idea as Snowflake's AT/BEFORE. Retention is governed directly by your VACUUM schedule rather than a separate Time Travel setting, so it's more visible but also more your responsibility to configure correctly.
Is Fabric cheaper than Snowflake?
It depends on your workload shape, and a flat answer either way is a guess. The billing models differ structurally — Snowflake credits meter each virtual warehouse independently, while Fabric Capacity Units are one shared, smoothed pool across every workload on the capacity. Teams running many small, independently-sized Snowflake warehouses often find the savings in consolidating onto one Fabric capacity — model your actual case in the CU cost calculator rather than assuming.
What's the hardest part of migrating from Snowflake?
Semi-structured data. Snowflake's VARIANT type has no direct Fabric equivalent — you decide per column whether to keep it as JSON text (query with OPENJSON) or shred it into typed columns during ingest. Shredding is more work up front and meaningfully cheaper to query for the life of the table.