Microsoft Fabric vs Snowflake: How to Choose in 2026

Last updated: October 2026

Many comparisons of Fabric and Snowflake were written when Fabric was new, and a good part of what they say is now out of date. Fabric Warehouse has since gained MERGE and, in August 2026, IDENTITY columns. OneLake added storage tiers in July 2026, capacity overage became generally available in September 2026 as an alternative to throttling, and Snowflake and Fabric reached general availability for reading each other's Iceberg tables at the start of 2026.

We build on both platforms, and the choice usually comes down to four questions: how your workloads share compute, what your SQL needs to do, where Power BI fits, and how access has to be controlled across teams. This guide works through each one using list prices and documented limits as of October 2026. Prices vary by region and change over time, so treat the figures as a starting point for your own estimate.

How each platform charges for compute and storage

Fabric sells capacity. You buy an F SKU, from F2 to F8192, where the number is the count of capacity units (CUs), and every Fabric workload in the workspaces assigned to that capacity draws on it. Snowflake sells credits. Each virtual warehouse consumes credits at a rate set by its size, and only while it is running.

Storage costs are close enough that they rarely decide the matter. Compute is where the models differ. Fabric charges for the capacity you provision, so it is good value when that capacity is kept busy across data engineering, warehousing and reporting. Snowflake charges for warehouses while they run, so it is good value when workloads are intermittent or bursty, and costs climb when warehouses are left running or sized too large.

Two Snowflake details have changed recently. Gen2 standard warehouses are now the default in most regions and consume 1.35 times the Gen1 rate on AWS and Google Cloud, or 1.25 times on Azure, so a Medium Gen2 warehouse on AWS uses 5.4 credits an hour. Adaptive warehouses, which are billed per query and require Enterprise Edition, are documented as generally available, although Snowflake's consumption table still labels them Preview.

Licensing for report readers also differs. On Fabric, users with a free licence can view Power BI content only when it sits on an F64 or larger capacity. Below F64, every viewer needs a Pro or Premium Per User licence, and Pro has cost $14 per user per month since 1 April 2025. This depends on the capacity that hosts the report, not on where the data comes from, so it applies equally to reports built on Snowflake.

What happens when demand exceeds what you bought

Fabric lets an operation use more compute than the capacity size, which Microsoft calls bursting, and then spreads its cost over later 30-second periods, which it calls smoothing. Interactive operations are smoothed over 5 to 64 minutes and background operations over 24 hours, and most Warehouse operations count as background. When smoothed usage runs too far ahead of the capacity, Fabric throttles in stages:

Throttling applies to the whole capacity. A large background job can therefore slow down or block Power BI users who happen to share the same capacity, which is why it is common to put engineering and reporting on separate capacities. Jobs that are already running are not throttled.

Capacity overage, generally available since September 2026, is the alternative to throttling. It bills usage above the SKU at three times the pay-as-you-go rate, which is $0.54 per CU-hour in East US. Microsoft's documentation says overage is enabled by default for new F capacities, although one page also describes it as opt-in, so we recommend checking the setting on every capacity. Overage stops at a rolling 24-hour threshold that defaults to 25%, and Microsoft notes that the threshold is not a hard spending cap. Spark has a separate opt-in, on-demand billing mode that runs Spark outside the capacity at pay-as-you-go rates, without smoothing or reservation discounts.

Snowflake isolates workloads by warehouse. When a warehouse is busy, new queries queue on that warehouse and nothing else is affected. Multi-cluster warehouses, available on Enterprise Edition, add clusters automatically when queries start to queue, and resource monitors can notify or suspend a warehouse when it reaches a credit quota. The trade-off is that every warehouse is a separate cost line to size and monitor.

SQL and data engineering

Fabric Warehouse uses T-SQL, which makes it attractive to teams coming from SQL Server or Synapse. It does not support the whole of T-SQL, and the gaps are the first thing we check on a SQL Server estate. Microsoft's documentation lists these among the unsupported features:

• Statements and objects: triggers, recursive queries, materialized views, synonyms, FOR XML, SET TRANSACTION ISOLATION LEVEL and manually created multi-column statistics. ALTER TABLE is only partly supported, and ALTER COLUMN was in preview in October 2026.
• Column data types: money, datetime, datetimeoffset, nvarchar, nchar, tinyint, geography, geometry, json and xml cannot be used in tables. datetime2 is limited to six decimal places and varchar(max) to 16 MB.
• Transactions: only snapshot isolation is available, and locks apply to whole tables, so two concurrent writes to different rows of the same table can conflict. Distributed transactions and savepoints are not supported.

Some of these, such as triggers, have no direct equivalent in Snowflake either, so the list is most useful for comparing Fabric Warehouse with the SQL Server code you already have.

The data type list matters most in practice, because nvarchar and datetime appear in almost every SQL Server schema. The locking behaviour matters for designs where several processes write small batches to the same table at the same time. Neither is a reason to rule Fabric out, but both belong in the estimate.

Two other points catch teams out. The SQL analytics endpoint over a Lakehouse is read-only for tables, so writes have to go through a Warehouse or through Spark. And Fabric Warehouse does not support connections across regions.

Snowflake uses its own SQL dialect, so a SQL Server migration to Snowflake involves conversion as well. Its stored procedures can be written in Snowflake Scripting, Python, Java or JavaScript. For Python data engineering, Snowpark runs DataFrame code inside Snowflake, while Fabric includes a full Spark environment in its Data Engineering workload. If your team already writes Spark, that is a point in Fabric's favour.

Power BI: Direct Lake against Import and DirectQuery

Direct Lake is the main reason Power BI-centred organisations look at Fabric. It reads Delta tables from OneLake into memory, so a refresh reloads metadata only, and it requires a Fabric capacity. There are two variants, and they behave differently when something goes wrong:

• Direct Lake on OneLake never falls back to DirectQuery. If a model exceeds a guardrail, the refresh fails. It also ignores row-level security defined on the SQL analytics endpoint.
• Direct Lake on SQL endpoints falls back to DirectQuery for views, for SQL row-level security and when a guardrail is exceeded. The "Direct Lake behavior" setting controls whether that fallback is allowed.

Guardrails scale with the SKU, for example 300 million rows per table on F2 to F8 and 1.5 billion rows on F64. Neither variant works through a gateway or across regions.

Power BI on Snowflake uses Import or DirectQuery. The Snowflake connector built on ADBC has been generally available since July 2025 and is now the default. Microsoft's documentation lists known issues with it, including wrong results for some count distinct queries and higher memory use, so we recommend testing distinct counts after switching. Entra single sign-on works with DirectQuery only. Our guide to DirectQuery vs Import on Snowflake covers the design choice in detail.

Authentication needs attention this year. Microsoft says username and password sign-in for the Snowflake connector will be deprecated, and Snowflake is ending password sign-in for non-human users by October 2026. Power BI datasets that refresh with a Snowflake service user and password should move to key-pair or Entra authentication.

Governance and access control

Fabric's access model starts with the workspace. The roles are Admin, Member, Contributor and Viewer, and Viewers cannot read OneLake data unless a OneLake security role grants it. OneLake security roles can restrict access to tables, folders, rows or columns, but they cannot restrict Admins, Members or Contributors, who see everything in the workspace. Row-level rules cannot be dynamic or span several tables, and column-level security behaves differently by engine: Spark drops the hidden columns, while SQL returns an error. Fabric Warehouse adds its own object, column and row-level security and dynamic data masking, and Microsoft Purview adds sensitivity labels, data loss prevention and audit.

Snowflake's model starts with roles. Every privilege is granted to a role, and row access policies and masking policies, which require Enterprise Edition or higher, apply to every query that touches the protected table, whichever role runs it. Row access policies also apply when Spark reads Snowflake Iceberg tables through Horizon. Private connectivity and Tri-Secret Secure require Business Critical Edition. One limitation affects Microsoft shops in particular: Entra ID provisioning through SCIM cannot provision nested groups.

The practical difference shows up when many teams share one platform. In Fabric, anyone with Contributor rights on a workspace sees all of its data, so separation is achieved through workspace design. In Snowflake, separation is achieved through roles and policies on shared databases. Our article on row-level security and masking in Snowflake shows the Snowflake side in detail.

Using both: Iceberg, OneLake and mirroring

Snowflake's release notes mark two-way Iceberg access with Fabric as generally available on 30 January 2026. In one direction, Fabric reads Snowflake-managed Iceberg tables through a Snowflake database item, and Direct Lake can use those items as a source. In the other, Snowflake reads tables in OneLake through a REST catalog integration, with read-only access. An older path also lets Snowflake on Azure write Iceberg tables into OneLake, provided Snowflake runs in the same region as the Fabric capacity and the workspace is not behind a private link.

Two practical points apply to the Snowflake database item. It works only over the public network, without gateway support. And Microsoft's setup example creates a Snowflake service user of type LEGACY_SERVICE that signs in with a password, which Snowflake's authentication changes in 2026 no longer allow for new users, so we recommend key-pair authentication instead.

Mirroring copies Snowflake data into Fabric continuously. It supports managed tables, Iceberg tables and views, with views synchronised every 12 hours, and it does not support external, transient, temporary or dynamic tables. Mirroring runs all the time and consumes Snowflake credits to do so, it has no direct Private Link option, and Snowflake's access policies do not carry over, so security has to be configured again in Fabric. On the Fabric side, replication compute is free and each CU of capacity includes 1 TB of mirroring storage. In September 2026 Microsoft added mirroring of Snowflake security roles, in preview.

We have written step-by-step guides to both patterns: Fabric mirroring with OneLake catalog integration and Azure SQL to Snowflake through OneLake.

How to choose

Most organisations can reach a decision by checking their situation against a short list. The table below reflects how we advise clients, and in several rows the honest answer is that either platform works.

Whichever way the table points, we recommend a two to four week proof of concept on your own workloads before committing: your largest Power BI models, your heaviest pipelines and a realistic number of concurrent users. Measure CU consumption on Fabric and credit consumption on Snowflake for the same work, and base the cost comparison on those measurements.