Here's a scenario that's becoming common enough to be a genre: an organisation has invested properly in Snowflake, it works, the data engineers like it, the revenue data lives there cleanly — and then Microsoft Fabric shows up in the industry conversation and someone senior asks, reasonably, "should we be using that instead? As well? At all?" I got to answer exactly that question this autumn on a revenue-insight proof-of-concept, and I want to write it up honestly, because the reflex answers — "rip out Snowflake" or "ignore Fabric" — are both wrong, and the real answer is a more useful shape than either. The mandatory caveat first: Fabric is still in preview, so everything here is a PoC judgement, not a production verdict.

The starting position

The setup was clean, which made it a good test. Revenue data — transactions, subscriptions, the numbers the business actually steers by — lived in Snowflake, modelled and reliable. Snowflake was not the problem. Nobody was unhappy with it, and I want to be clear about that up front, because a lot of "should we adopt X" PoCs are secretly "we're unhappy with Y" projects wearing a lab coat. This wasn't. Snowflake was doing its job well.

The actual question was narrower and better: does putting Fabric on top of a healthy Snowflake add enough value, in the reporting and insight layer, to justify the second platform? Not "which warehouse wins" — a tediously overdone framing — but "is there a division of labour where each does what it's best at?"

What each side is genuinely good at

To answer that without falling into vendor tribalism, I find it clarifying to name what each platform is actually strong at, plainly:

  • Snowflake is an excellent, mature cloud data warehouse: strong at storing and querying large structured data, well-liked by engineers, cross-cloud, and — crucially here — already working and already trusted for this organisation's revenue data. That last point is not a technical feature but it is a real asset. Trusted infrastructure has value that a feature comparison misses.
  • Fabric — in preview — is trying to be a whole analytics platform, and its centre of gravity for this scenario is the tight coupling between OneLake, its Power BI layer, and the Microsoft ecosystem the business already lived in (Office, Teams, Azure identity). Its pitch isn't "better warehouse than Snowflake." Its pitch is "the insight and BI experience on top, closely wired into the tools your business users are already in."

Read that way, they're not really competing for the same job. Snowflake is a superb warehouse. Fabric's relevant strength here is as an insight and delivery layer. The interesting architecture is the one that lets each do the half it's better at.

The PoC we actually built

So rather than a migration, we prototyped a cooperation. The pattern:

  1. Leave revenue where it lives. Snowflake stayed the system of record for the revenue data. No rip-out, no re-modelling of the thing that already worked. Moving trusted data for the sake of a preview platform would have been reckless.
  2. Bring curated marts into Fabric, not the whole warehouse. Using Fabric's data pipelines, we pulled the specific, curated revenue marts the insight work needed into a Fabric lakehouse — a slice, refreshed on a schedule, not a mirror of all of Snowflake. For the more live-facing views we also tested Power BI querying Snowflake directly, to compare the "copy a slice into OneLake" and "leave it in place and query through" approaches head to head.
  3. Do the insight layer in Fabric. The Power BI reporting, the metrics, and the business-facing delivery — all wired into the Microsoft tools the revenue team already worked in — happened on the Fabric side, over that curated slice.

The point of the PoC was to find out whether that seam — Snowflake as warehouse, Fabric as insight layer, a curated slice crossing between them — was smooth enough to be worth the second platform, or whether the integration tax ate the benefit.

What we learned

Genuinely useful findings, in both directions:

  • The cooperation pattern is sound in principle, rough in preview practice. The idea — warehouse in Snowflake, insight in Fabric, a governed slice between — held up well conceptually. The execution, on preview software, had the expected sharp edges: the connectors and pipelines worked but not always predictably, and I wouldn't yet promise a facilities-grade SLA on any of it. Sound design, immature tooling — a normal preview verdict.
  • "Bring a slice" beat "query everything through," for this workload. Copying the curated marts into OneLake gave the BI layer better, more predictable performance than routing every report query back to Snowflake live — at the cost of a refresh to manage and a copy to govern. The direct-query approach was tempting for its simplicity and its no-copy honesty, but the report experience wasn't as crisp. Your mileage depends heavily on data volumes and how live the numbers must be; for revenue reporting that's fine a few hours old, the slice won.
  • The real value was ecosystem gravity, not warehouse features. Where Fabric earned its place was not by doing anything Snowflake couldn't — it was by putting the insight, natively, inside the Microsoft tools the business already lived in. For an organisation deep in Office and Teams and Azure identity, that closeness is a genuine benefit. For an organisation that isn't, it mostly evaporates, and the honest recommendation would tilt back toward keeping it simple on Snowflake.
  • The cost picture stayed foggy. Two platforms means two bills and a new integration to run, and Fabric's preview cost model made the total hard to forecast. A cooperation architecture has to clear that added cost in delivered value, and whether it does is organisation-specific, not universal.
The good question was never "Snowflake or Fabric." It was "what is each genuinely best at, and is the seam between them worth running?" A healthy Snowflake plus a Microsoft-native insight layer is a real pattern — but only for an organisation already living in the Microsoft world, and only once the preview tooling grows up.

The honest recommendation

I closed the PoC without a triumphant single answer, because a triumphant single answer would have been a lie. What I gave instead was conditional, which is what these questions actually deserve. If you're deep in the Microsoft ecosystem, value the insight layer landing right inside the tools your business already uses, and can wait for Fabric to leave preview before anything goes live — then the cooperation pattern, Snowflake below and Fabric on top, is worth prototyping seriously and adopting when it matures. If you're not especially Microsoft-centric, or you need this in production now, or the added cost and integration can't clearly earn their keep — then the right call is to keep doing the insight work well on the platform you already trust, and not add a second one for the sake of a logo.

That's the vendor-neutral read, and I'll defend it against both tribes. This isn't a story where Fabric heroically displaces Snowflake, nor one where a mature warehouse makes a preview platform irrelevant. It's a story about division of labour — each platform doing the half it's genuinely better at — and about being honest that the division only pays off under specific conditions. Name your conditions first. Then decide. The moment you let the platform choose the architecture instead of the architecture choosing the platform, you've already lost the plot — and probably signed for two bills where one would have done.