I make my living, largely, in the Microsoft data stack. I know Fabric's plumbing, I've untangled more Synapse workspaces than I can count, and Power BI is close to muscle memory. So when I tell a client that Microsoft isn't the answer for what they're trying to do, they tend to believe me — precisely because it costs me something to say it. That credibility is the whole reason I guard the position. An advisor who only ever recommends the thing they know best isn't an advisor; they're a salesperson with a narrower catalogue. So let me do the thing that keeps the advice worth having, and lay out — honestly — where I'd steer you away from the stack I love.
First, the necessary caveat, because context decides everything. For a great many organisations — especially the ones already living in Microsoft 365, Azure, and Entra — Fabric or the wider Azure data platform is genuinely the right call, and not because it's fashionable. The integration is real, the skills are findable, the licensing folds into agreements you already have, and the gravity of an existing ecosystem is a legitimate architectural force, not a lazy one. I'm not staging a contrarian takedown here. I'm marking the edges of the map — the places where the sensible default stops being sensible.
When your centre of gravity is data science, not BI
If the beating heart of your work is machine learning — heavy experimentation, large-scale training, a data-science team that lives in notebooks and wants fine-grained control over compute and their MLOps toolchain — then a Databricks-centred architecture will very often serve you better than trying to make Fabric the whole world. Fabric has a real and improving data-science surface, and for a BI-first shop that does some ML it's perfectly adequate. But if ML is the main event rather than a supporting act, the platform built from the Spark-and-notebooks direction outward tends to fit the team's hands better than the one built from the BI direction outward. Match the platform to where your centre of gravity actually sits, not to where you wish it did.
When the warehouse is the crown jewel and neutrality is the point
There's a class of organisation — often multi-cloud by deliberate strategy, or wary of concentrating everything with a single vendor — for whom a best-of-breed cloud warehouse like Snowflake is the wiser core. If cross-cloud portability is a board-level requirement, if you want your warehouse deliberately decoupled from any one hyperscaler's ecosystem, or if your data-sharing model spans partners on different clouds, that neutrality is worth paying for. Fabric's tight weave into the Microsoft world is its great strength for Microsoft shops and precisely the wrong property for an organisation whose strategy is not to be locked to Microsoft. Know which of those you are before you commit.
When you're too small for the machinery
Not every failure of fit is at the high end. I've watched small organisations talk themselves into a full Fabric capacity — with the governance, the capacity management, the operational overhead it implies — when what they actually needed was a handful of well-made Power BI reports on a Pro licence, or a small warehouse and a scheduled job. A platform can be too big for you. If you don't have the scale, the team, or the appetite to run the machinery, the machinery becomes a cost centre that produces meetings instead of insight. The honest recommendation is sometimes "you need much less than you've been sold."
When extreme, low-latency streaming is the whole job
Fabric's Real-Time Intelligence has come a long way, and for most organisations' streaming needs it's more than enough. But if genuinely low-latency, very-high-throughput event processing is the core of your product — the kind of workload that lives and dies on a dedicated Kafka/Flink pipeline tuned to the millisecond — then a purpose-built streaming stack will out-serve a general platform that happens to include streaming. This is the same principle again: a broad platform is a wonderful default and rarely the best specialist.
The pattern, and its limit
Reread those and the rule underneath is simple: a broad, integrated platform is the right default and almost never the right specialist. Microsoft's data stack is an outstanding generalist — it does eighty per cent of what most organisations need, coherently, with skills you can hire and licensing you already own. You should reach for a specialist only when one of those specialist properties — ML-first, deliberately vendor-neutral, extreme streaming, or radically smaller scale — is genuinely central to your situation, not merely present in a slide.
It cuts both ways, though, and I hold this with equal conviction: do not assemble a zoo of best-of-breed specialists to chase a theoretical optimum you'll never realise. I've seen organisations stitch together five best-in-class tools and drown in the integration tax — the connectors, the duplicated governance, the five vendors to manage, the skills matrix nobody can hire against. For most people, most of the time, the coherent generalist beats the optimised menagerie, because architecture is judged on what you can actually operate, not on a feature matrix. The times Microsoft isn't the answer are real and worth naming — but they're the exceptions that prove how good a default it is.
This is the same discipline I keep coming back to: being Microsoft-deep and vendor-honest at once. The depth is what lets me see the edges clearly. The honesty is what makes it safe for you to trust me when I point at one. If your advisor has never once told you to walk away from their favourite tool, you should wonder whether they can see the edges at all — or whether they're just hoping you won't ask.