Which Azure Analytics Service Do You *Actually* Need? A Decision Tree for SMEs

I predicted at the start of last year that Fabric would become the default starting point for analytics on Azure, and it has — comfortably. But "default" has a failure mode that's now everywhere I look: people hearing "default" as "only," and reaching for Fabric reflexively for every problem, including the ones it's the wrong tool for. So here's the corrective, in the form of the decision tree I actually walk through with clients. It's Fabric-first, because that's the honest starting point in 2025. It is emphatically not Fabric-only.

The goal isn't to talk you out of Fabric. It's to make sure that when you land on it, you chose it — and that you can recognise the genuine cases where something else is the right answer.

Start with the questions, not the products

The mistake is starting from the product catalogue — "should we use Synapse or Databricks or Fabric?" — because that invites a feature comparison that misses what actually decides it: the shape of your problem and your team. So start here instead, in order:

1. Is this mostly BI and analytics for business consumers, on the Microsoft stack? If yes, and you're not carrying heavy specialist requirements, Fabric is very likely your answer — it's built for exactly this, it's where Microsoft is investing, and it gives you the integrated path from data to governed semantic model to Power BI. Most organisations, most of the time, stop here. That's fine; that's what "default" means.
2. Do you have serious, existing data-science and heavy-engineering workloads — big Spark, ML at scale, a team that lives in notebooks? If that's the centre of gravity, be honest about whether Fabric's Spark experience meets you where you already are, or whether a dedicated Databricks deployment — more mature for heavy data engineering and ML — is the better home, with Fabric consuming its outputs. Fabric and Databricks coexisting is a completely legitimate architecture, not a failure to commit.
3. Do you need genuine, sub-second, high-volume real-time or log/telemetry analytics? If your problem is truly operational — streaming at scale, observability, time-series at volume — the specialist engines (the Kusto/Real-Time Intelligence lineage) are purpose-built for it in ways a general platform isn't. I've watched people force real-time telemetry through the wrong tool because it was the default, and pay for it in reliability.
4. Is this actually small enough that a plain database would do? The most under-used answer of all. A surprising number of "analytics platform" requirements are a modest amount of data and a few reports — for which Azure SQL and Power BI, with no lakehouse in sight, is cheaper, simpler, and entirely sufficient. Not every analytics need requires an analytics platform.

Notice that only after working through those do you arrive at a product — and that the tree sends most people to Fabric while deliberately catching the ones it would fail.

Why "default" needs the discipline of a tree

Here's why I bother with a decision tree at all, rather than just saying "use Fabric." A default is enormously useful — it saves you from re-litigating the obvious choice every time — but it's dangerous precisely because it removes the moment of thinking. When Fabric is the reflex, the cases where it's wrong don't announce themselves; they just quietly become expensive or unreliable six months later, and everyone wonders why.

The tree restores the thinking without restoring the agony. For the majority of cases it confirms Fabric quickly and you move on. Its real value is in the minority — the heavy data-science shop, the genuine real-time problem, the job that a plain database would have handled — where it stops you defaulting into a mismatch. That minority is small, but the mistakes in it are the costly ones, which is exactly why they deserve a checkpoint.

A good default saves you from thinking about the easy cases. A good decision tree makes sure you still think about the hard ones. You want both — the default for speed, the tree for the exceptions the default would quietly ruin.

The constraint that can override the whole tree

One more thing, because it sits above the tree rather than inside it: regulatory and data-residency constraints can override every branch above. If you're in a regulated or semi-public setting — healthcare, government, finance — where data must stay in a specific region, or where certain data can't touch certain services, that constraint doesn't get weighed against the others. It wins outright.

I've watched clean, sensible tool choices get correctly overturned by a single sentence from legal about where data is allowed to live. So before you run the tree at all, ask whether any hard external rule already narrows your options — because there's no point optimising for the ideal engine if compliance has quietly already made the decision for you. Better to discover that first than to design the perfect architecture you're not permitted to build.

The honest bottom line

If you take one thing from this: Fabric-first is right, and Fabric-only is a trap. In 2025, starting from Fabric for analytics on Azure is the sensible posture, and for most organisations most of the time the decision tree lands there fast. But the credibility of "Fabric-first" depends entirely on your willingness to say "not this time" when the problem genuinely calls for Databricks, or a real-time engine, or — most often overlooked — nothing more than a database and a couple of reports.

Vendor-neutrality inside a Microsoft-deep practice isn't a contradiction; it's what makes the Microsoft-deep recommendation trustworthy. When I tell a client Fabric is the answer, it means something precisely because they've heard me tell other clients it isn't. Use the default. Keep the tree. And reserve the right, every time, to reach the end of it and choose something else.