AnswersMicrosoft Fabric
Fabric, Snowflake or Databricks: how do you choose?
Rob CollieFounder and CEO, P3 Adaptive
Start from where your people already work. If that is Power BI, Fabric usually fits best. All three will store and transform your data well, and each one arrives with a sales team that finds its own platform the obvious choice. In practice the decision turns on where people read the numbers and what your data team already knows. If you already run Snowflake or Databricks and it works, keep it. You do not need to rip and replace a working platform to get good Power BI on top.
If you are asking this, you are probably being pitched by at least two of them. Each pitch is good. Each one ends with the same platform winning, and it is always the one the person pitching happens to sell.
So let me say where I sit. I spent thirteen years at Microsoft and was a founding engineer on Power BI, and P3 has worked on Microsoft’s data platform since 2013. We are Microsoft-native and I am not going to pretend otherwise. Read what follows knowing that. I will try to be fair to the other two, because the fair version is also the one that holds up when you go and check.
The engines are closer than the marketing
Ten years ago these were very different things. Snowflake was a cloud data warehouse. Databricks was Spark, for data engineers and data scientists. Fabric didn’t exist.
They have been growing toward each other ever since. All three will land data from your systems, store it in open table formats, transform it with SQL or Python and serve it to a BI tool. Any of them can run a well-built lakehouse. You can find a benchmark showing each one winning, and I wouldn’t pick a platform on any of them.
What decides it is your people, and what they already do all day.
Three questions that settle most of it
Where do people read the numbers?
If most of your company reads reports in Power BI, inside Teams and Excel and the rest of Microsoft 365, that pulls hard toward Fabric. The data, the models and the reports share one tenant and the same sign-in. With the other two, Power BI connects across a boundary. That works fine. It is one more connection to secure and keep healthy.
What does your data team already know?
A team fluent in SQL tends to be productive in Snowflake quickly. Spark engineers and data scientists who live in notebooks usually like Databricks. A small team whose strongest skills are Power BI and Power Query will find Fabric the shortest step, because a lot of it already looks familiar. Retraining is a real cost, and it rarely shows up in the comparison spreadsheet.
Where will the semantic layer live?
Somebody has to write down what revenue means. That can live in the warehouse, in the metrics layers Snowflake and Databricks now offer, or in a Power BI semantic model. Pick one home on purpose. Two homes is how you end up with two numbers.
When each one fits
Fabric
Your company lives in Power BI and Microsoft 365. Your data team is small, and the people who know your data best are Power BI people. You would rather govern everything in one place with one vendor. That describes most of the companies we talk to, which is partly selection bias. They call us because they are already on Microsoft.
Snowflake
You have a real SQL-first data team, several BI tools across the business, or partners who need governed access to shared data. You want a warehouse that mostly runs itself. Snowflake is very good at that, and plenty of companies run it with Power BI on top quite happily.
Databricks
Your heavy lifting is engineering and data science: big volumes, streaming, machine learning, people who think in notebooks. Databricks was built for that crowd and it shows. Reporting sits downstream, and very often that means Power BI.
If you already run Snowflake or Databricks
Keep it. You do not need to rip and replace a working data platform to adopt Fabric, and I would be suspicious of anybody who tells you that you do.
A migration looks cheap on a slide. In real life it is months of rebuilding pipelines that already work and re-testing numbers people already trust. Your team was productive the week before it started. You spend all of that to arrive roughly where you began.
Power BI connects to both directly, and a lot of well-run companies have exactly that setup. Fabric can also reach into them without a rebuild. Shortcuts and mirroring can make Snowflake or Databricks tables available in OneLake while the data stays managed where it is. That leaves room to use Fabric for new work, like the messy API source nobody has landed yet, while the existing platform keeps doing its job.
The semantic model matters whichever platform you pick
This is the part I care about most, and the platform comparison usually skips it.
A warehouse holds tables. Somebody asking how the West region did last quarter needs a lot more than tables. They need to know which table is the real one, what counts as revenue, how returns are handled and which date the quarter hangs on. That knowledge lives in the semantic model, and it decides whether the answer is right.
It matters even more once you put an AI assistant in front of the data. An assistant reads exactly what is written in the model and nothing else. A good model on an average platform beats a weak model on a great one almost every time. I went into that in why your AI can’t answer questions about your own data.
So whatever you choose underneath, budget real time for the model. Some teams want the definitions to live with the data, in the warehouse’s own metrics layer, and that can work. The Power BI semantic model is still the most capable one I know of, and it is where your report readers already are. Choose one place and put the definitions there.
Pick the platform your people can run. Then spend the real effort on the model, because the model is where the right answer comes from.
Mixed estates are normal
Plenty of companies end up with more than one of these. An acquisition brings a Databricks team. A product group has had Snowflake for years. Finance moved onto Fabric last spring. That is fine on its own. The mess shows up when each one grows its own definitions and its own reports, and nobody can say which number is right.
What helps is one place where people find the models and ask them questions, whatever platform feeds them. That is part of why we built Faucet, our platform, to sit on top of the semantic models across a mixed estate. You can solve it other ways. You do have to solve it.
The paths we see most
All in on Fabric
You are Microsoft-first and don’t have a data platform worth keeping yet. Build the lakehouse in Fabric one source at a time, and let working reports tell you which source goes first.
Keep what works, Power BI on top
You have Snowflake or Databricks and it is doing its job. Leave it there. Put the effort into the semantic model and the reports, and connect across.
Both, on purpose
Your existing platform keeps the work it is good at. Fabric takes the new sources and the Power BI side, reading existing tables through shortcuts or mirroring so nobody rebuilds a pipeline that already runs.
A word on cost
I am not going to quote prices. They change, they depend on your workload, and any number on a page like this would be stale by the time you read it.
The billing models do differ. Fabric is sold as capacity you size and pay for while it runs. Snowflake and Databricks mostly bill on what you consume. Either can come out cheaper for a given company. What catches people out is the workload nobody modeled, like the refresh that runs every fifteen minutes or the notebook somebody forgot to shut down. Price your real workload on each, and remember that Power BI licensing sits on the bill whichever warehouse is underneath.
Four things you can check by Friday
Diagnostic
Which way does your company already lean?
You probably know more about the answer than the vendors do.
Pull last month’s report usage. Where did people actually open reports?
If it is nearly all Power BI, that tells you where the platform should sit, and it tells you more than any benchmark will.
Ask your data team what they would reach for to build a new pipeline tomorrow.
Weight their honest answer heavily. A platform your team resents tends to stay half built.
Find where revenue is defined today. Count the places.
More than one means the platform decision comes second. Settle the definition and pick its home first.
If you already have a data platform, list what would break if you switched it off tomorrow.
A long list means it is load-bearing. Build around it, and ask anyone proposing a migration what you get back for the months it costs.
Where I’d start
Don’t settle this in a conference room. Take one question the business keeps asking and can’t get answered. Build the report and the model for it on whatever data you can get this week, and put it in front of the people who asked.
That shows you which sources matter, how fresh they have to be and how much engineering they really need. With that in hand the platform question usually gets a lot smaller. If your people are in Power BI, it tends to land on Fabric, and I wrote about when you actually need Fabric separately. If you already have a platform that works, it tends to land on keeping it.
Tell us what you run today.
Bring the platform you have, or the proposals sitting on your desk. We will give you a straight read on what fits, including when the answer is to keep what you already own.