Snowflake vs Databricks vs Microsoft Fabric: an architecture fit assessment

1. Executive summary

Here is the uncomfortable summary: all three are Adopt, none of them will lose you the project, and the decision is mostly not technical. I have watched teams spend two quarters on a bake-off whose answer was determined on day one by which cloud their identity provider lives in. That is not a failure of analysis — it is the correct answer arriving early and nobody believing it.

What genuinely separates them in 2026 is narrower than the marketing suggests. Iceberg has quietly removed the strongest lock-in argument each vendor had: Snowflake shipped first-class Iceberg tables and donated the Polaris catalog to the Apache Software Foundation; Databricks exposes Delta as Iceberg through UniForm without copying data. When your tables can be read by someone else's engine, "which engine" stops being a life sentence and starts being a procurement decision you can revisit.

So the axes that actually decide it are elasticity, governance depth, and the shape of your team — not query speed. On raw scan performance a dedicated engine like ClickHouse beats all three, and that is fine, because none of these is trying to win that fight.

2. Positioning

These three are not the same kind of product, which is the first thing to get straight before comparing numbers.

Snowflake is a cloud data warehouse that grew up — separating storage and compute long before it was fashionable, then expanding outward into data engineering (Snowpark), sharing, applications, and AI (Cortex). Its instincts are a warehouse's instincts: SQL first, governance first, and an operational model designed so that nobody has to think about it. Databricks came from the other direction — Spark-as-a-service that grew into a unified analytics and AI platform on Delta Lake, with Unity Catalog for governance and MLflow for the ML lifecycle. Its instincts are a lake's instincts: files first, any workload, maximum flexibility. Microsoft Fabric is the newest and is best understood as neither: it is a bet that integration beats capability, wrapping OneLake, Power BI, and the Microsoft governance estate into one SaaS surface billed by capacity.

The 2026 shift worth internalising: Iceberg is the most strategic factor in the buying decision, and it argues against caring so much about the buying decision. Running two of these deliberately is now a legitimate architecture rather than an admission of failure — Databricks handling ingestion and training upstream, Snowflake serving BI and sharing downstream, both reading the same Iceberg tables without a copy. I would not start there. But it is a reasonable place to end up, and knowing that takes the temperature out of the bake-off.

3. Radar criteria — the reasoning

Query performance

Close enough that it should rarely decide anything. Databricks 4.4 on Photon and a decade of Spark tuning; Snowflake 4.2, extremely consistent and almost impossible to make slow by accident, which is worth more in practice than a benchmark win; Fabric 3.8, competent but the clearest ceiling of the three. For scale: I scored ClickHouse 4.7 on this axis. If raw scan speed is your binding constraint, none of these three is the answer.

Real-time ingestion

All three have made this materially better and none is a streaming-first engine. Databricks 4.0 (Structured Streaming is genuinely good and genuinely fiddly); Fabric 3.9 — Eventstream and the KQL Eventhouse are an underrated part of the product and the one axis where Fabric is not last; Snowflake 3.6, where Snowpipe Streaming and Dynamic Tables are real but seconds-to-minutes is the honest freshness story. See my Snowpipe Streaming deep-dive for why that number is not higher.

Lakehouse fit

Databricks 4.8 and this is its home field — Delta plus UniForm plus Unity Catalog is the most coherent lakehouse story anyone ships. Fabric 4.3: OneLake is a genuinely good idea, one logical lake for the whole tenant. Snowflake 4.1, up substantially on Iceberg tables and Polaris, and still with a warehouse's instincts about where data ought to live.

SQL & data modeling

Snowflake 4.7 — the best SQL surface in the category, and it is not close. Databricks 4.4, much improved and still carrying Spark ergonomics into places where you wanted a warehouse. Fabric 4.0, adequate, with the T-SQL/Spark split showing at the seams.

Cloud elasticity & scalability

Snowflake and Databricks tie at 4.6 — both do genuine compute/storage separation and elastic scaling, and both make it easy. Fabric 4.0: the F-SKU capacity model is pre-purchased elasticity, which is a different and less forgiving thing. You cannot burst past a capacity you did not buy.

Reliability / HA / DR

Snowflake 4.8, Databricks 4.6, Fabric 4.1. Snowflake's operational track record is the quiet reason a lot of enterprises pick it, and it does not show up in any feature comparison. Time travel, cloning, cross-region replication, and an availability record you don't think about.

Governance & security

Snowflake 4.8 and Databricks 4.7 are both excellent and have converged. Fabric 4.4 is close behind on features and ahead of both on something the axis undersells: if your identity, DLP, and compliance already live in Entra and Purview, Fabric inherits them rather than reimplementing them. That is worth real money in an audit.

Operations & observability

Snowflake 4.6 — the least operational surface of any platform I assess. Databricks 4.3: better than its reputation now, but clusters, job hygiene, and runtime versions are still yours. Fabric 3.8 — capacity management is an ops burden that presents itself as a billing setting, which is exactly why teams get caught by it.

Ecosystem integration

Databricks 4.7 and Snowflake 4.6 are both effectively universal. Fabric 4.2 — magnificent inside the Microsoft estate, ordinary outside it. That is the whole product thesis, stated as a score.

TCO & cost efficiency

The worst axis for all three, and the honest one: Fabric 3.6, Databricks 3.4, Snowflake 3.2. Note this is not a claim about list price. It is about how easily the platform lets you waste money. Snowflake's per-second credits are the most predictable and the easiest to leave running; Databricks' DBU-plus-infrastructure is the hardest to forecast; Fabric's fixed capacity is the most predictable of all right up until you need more of it, at which point the step function is brutal. A well-governed Snowflake deployment routinely costs less than a poorly-governed Fabric capacity, which tells you the governance matters more than the pricing model.

4. Radar scorecard

How these scores are arrived at — the rings, the 0–5 scale, and the evidence rules — is written up in the radar methodology. This table and the chart below are generated from one file, scorecards.json: the source of truth, machine-readable, and kept separate so two copies of the same numbers cannot drift apart between editions. Last reviewed 2026-Q3.

Comparator scores (same axis order) — Databricks: 4.4 / 4 / 4.8 / 4.4 / 4.6 / 4.6 / 4.7 / 4.3 / 4.7 / 3.4. Microsoft Fabric: 3.8 / 3.9 / 4.3 / 4 / 4 / 4.1 / 4.4 / 3.8 / 4.2 / 3.6.

5. The radar

Ten-axis fit for the warehouse-lakehouse-of-record use case. The shapes are strikingly similar — which is the finding. Databricks bulges toward the lake, Snowflake toward SQL and operational calm, Fabric sits inside both and trades ceiling for integration. Note that all three dip on cost. Click any name in the legend to toggle it on or off — comparing two shapes at a time is far more legible than comparing four.

6. Workload-specific analysis

7. Reference architecture

The pattern I would build for the target use case is deliberately boring, and its most important property is the seam: the lake and its catalog sit in the middle so the engine above them is replaceable. That is the whole dividend Iceberg pays.

graph LR
  S["Source systems"] --> IN["Ingest
CDC / batch / stream"]
  IN --> L[("Object storage")]
  L --> T["Open table format
Iceberg / Delta"]
  T --> C["Catalog
Polaris / Unity / OneLake"]
  C --> E["Engine
Snowflake / Databricks / Fabric"]
  E --> M["Transformation
dbt"]
  M --> G["Curated marts
+ metrics layer"]
  G --> BI["BI / Power BI / Tableau"]
  G --> AI["ML / AI workloads"]
  E -.->|"hot serving"| H[("ClickHouse /
StarRocks")]
  H --> APP["Customer-facing apps"]
  GOV["Identity / RBAC
/ lineage"] -.->|"governs"| C

The one piece of configuration I would put in the first sprint on any of the three, because it is the difference between a platform and a bill:

-- Snowflake: the cost control that matters more than the pricing model.
-- An idle warehouse nobody suspended is the single most common way to
-- overspend on any of these three platforms.
ALTER WAREHOUSE bi_wh SET
  AUTO_SUSPEND = 60          -- seconds of idle before it stops
  AUTO_RESUME  = TRUE
  WAREHOUSE_SIZE = 'MEDIUM'  -- right-size, then measure; don't start large
  STATEMENT_TIMEOUT_IN_SECONDS = 900;

-- Then make overspend visible before the invoice does.
CREATE RESOURCE MONITOR bi_monitor WITH
  CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS ON 75 PERCENT DO NOTIFY
           ON 90 PERCENT DO SUSPEND
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;

8. POC plan (4 weeks)

• Week 1 — disqualify, don't rank. Take your three ugliest real workloads and ask only one question of each platform: is there a disqualifying gap? Not "which is faster" — which cannot do this at all. Most weeks, the answer is none, and that is a finding worth having in writing.
• Week 2 — governance against your actual identity estate. Wire each to your real IdP and reproduce your hardest access-control requirement, not a toy one. This is where Fabric either wins outright or stops mattering, and it takes days rather than the quarter people fear.
• Week 3 — model the bill, not the benchmark. Run a fortnight of representative load and extrapolate. Include idle time, dev environments, and the BI tool's refresh pattern — that last one has ended more Fabric capacities than any query. Cost is the lowest score on the board for all three; it deserves the most POC time and gets the least.
• Week 4 — decide, and be honest about why. Re-score this table with your numbers. If the deciding factor turns out to be "our identity lives in Entra" or "our team knows Spark", write that in the ADR as the reason. A decision made on real constraints is defensible; the same decision dressed up as a benchmark result is not, and everyone can tell.

9. Final recommendation

All three are Adopt. Pick on your constraints, not on a scorecard — including this one.

Choose Snowflake when the platform must be boring and correct: governed SQL serving, data sharing, a small platform team, and an organisation that would rather not think about infrastructure. It has the best SQL surface and the least operational surface of anything in this category, and those two facts carry more weight in year three than any benchmark does in week one.

Choose Databricks when the lake and the models are the point. If your centre of gravity is ingestion, transformation at scale, and training — rather than serving dashboards — it is the most coherent platform available, and Unity plus UniForm means choosing it no longer means giving up open formats. Pay for that with a real operational surface and a bill that is genuinely harder to forecast.

Choose Fabric if you are a Microsoft estate, and do so without apology. Every technical axis here says it has a lower ceiling than the other two, and for a large number of organisations that ceiling sits well above anything they will actually reach — while the integration with Entra, Purview, and Power BI is worth more than the headroom they are giving up. Just staff the capacity management, because it is an operational discipline wearing a billing setting's clothes.

What I would not do: pick any of them for sub-second customer-facing analytics, and expect the platform to impose cost discipline you don't have. Cost is the lowest-scoring axis for all three, and it is the one that ends deployments. Re-assess this page when Iceberg interop matures further — every step it takes makes this decision smaller, which is the best news in the category.

References

The vendor engineering blogs below are evidence about mechanism and marketing about benefit; I have used them for the former. There is no neutral benchmark of these three that I would put weight on, which is itself worth knowing.

Scores are my own architect-level judgment for the stated use case, calibrated to mid-2026 — not a vendor ranking. The axes match my other analytics assessments, so scores are comparable across them. Re-score against your own POC numbers before you commit.