Power BI or Fabric: what a smaller company needs

The question almost always arrives in the same form. Someone has read somewhere that Fabric is the successor to Power BI, and wants to know whether they should move over.

The short answer: Fabric is not a successor. It is a different thing, with a different pricing model, for a different kind of problem. And at most of the smaller companies that ask me, it solves a problem they do not have.

The difference in one paragraph

Power BI is the layer where you model and show your numbers. Reports, dashboards, a data model underneath, users looking at it. You pay per user.

Fabric is the platform under that. Storage, processing, pipelines, a lakehouse, notebooks. You are not buying users but capacity, and that capacity is either there or it is not. Power BI sits inside it as a component.

That difference in pricing model is the most important thing to understand. With Power BI your cost scales with the number of people looking. With Fabric your cost scales with the capacity you reserve, regardless of how much of it you actually use. For a large organization that is an advantage. For a company with eight people opening a dashboard it rarely is. Always check the current rates, by the way, they move.

The client I talked out of it

At one small company Fabric was concretely on the table. It would have cost a serious amount of money, every month, for something they did not need at that point.

We solved it differently. The data sits in Neon, a hosted PostgreSQL you can start on for a fraction of the cost. The processing runs in Python, scheduled with an ordinary scheduler. Power BI sits on top as the visualization layer. That is not a compromise, it is simply the right size for the volume involved.

I am not saying Fabric is bad. I am saying you only need it once your volume or your organization justifies it, and that you will notice that moment yourself. You should not move there because it is new.

The platform is rarely your bottleneck

Here is the real point. In almost every project I do, the bottleneck is not the tool.

Take Excel, which is where most smaller companies come from. Why does an Excel report break? Rarely because of Excel. It breaks because several people work in the same file. Because someone renames a column. Because there is no unique identifier in the data, so you cannot reliably join two lists. Because someone saves it wrong.

Those are all problems of structure and agreements. They simply travel along to the next platform if you do not solve them. A more expensive tool does not make a bad data model better, it only makes it bad faster.

The same goes for definitions. At one client, active customer turned out to mean three different things. The definition everyone agreed on was: someone who ordered in the past twelve months. Sounds watertight. It is not, because frequency says far more than the fact that something was once ordered. Someone who buys every month and someone who buys once a year are not the same customer, and yet they landed in the same category.

Settling questions like that costs an afternoon. Skipping them costs you a year of reports nobody dares to steer on.

What you do not look at enough

There is something else I see at almost every smaller company, and colleagues do not always agree with me on it.

People look far too narrowly. Accounting figures, maybe an export out of Odoo, and that is the whole picture. Only the essence often sits nowhere near those sources.

In retail, for instance: footfall, meaning how many people walk in. Conversion, how many of them buy something. IPT, the number of items per transaction. None of those three is in your bookkeeping, and together they explain your revenue better than your revenue figure does on its own. If revenue drops, you want to know whether fewer people came in, or whether just as many came in but fewer bought, or whether they bought but less per visit. Those are three different problems with three different solutions.

Anyone looking only at the bookkeeping never sees that difference. And that is not a platform question, it is a question of which sources you bring in.

When Fabric does make sense

For completeness, because I do not want to come across as being against it. Fabric gets interesting when you have several heavy data sources you genuinely need to process rather than just read, when you start doing data science, or when you have enough users that the licensing model tips. Then it is a good choice and I say so.

It is just that, at the companies I walk into, that is the exception rather than the rule.

Why we build first

This is also why we do the first phase for free, and that is not a sales trick. By building, I see where it goes wrong. Which source is messy, which definition does not hold, where the real bottleneck sits.

I cannot judge that in an intake meeting, and you cannot tell me, because if you knew you would not need me. Only once something is running do we both know whether there should be a next step and what it would be about. Often that is something other than what the conversation started with.

The claim

Do not pick a platform before you know which question you want answered and which sources the answer has to come from. Nine times out of ten your bottleneck is your data model, your definitions or a source you are not yet bringing in. None of those three gets solved by an invoice from Microsoft.