Metabase or Power BI: what decides it for a small team

Metabase is the better answer when the people with the questions build their own, and the rows must stay in a database you already operate. Power BI is the better answer when one person owns the model and publishes to readers, and the company already runs on Microsoft accounts. What decides it is not the chart library, but who is expected to build the report and where the data may live.

Who is expected to build the report?

In Metabase, the person with the question builds it: open a browser, pick a table, choose a metric and a grouping, save the chart. SQL is there for those who want it, and a model can centralise the joins so everyone starts from the same tables.

In Power BI, one person authors and everyone else reads. Authoring is a desktop application — tables, relationships, measures — followed by a publish to a workspace. A reader filters and drills, and cannot usually extend.

Each moves the cost rather than removing it: with Metabase it lands on consistency, because ten people can define an active customer ten ways; with Power BI it lands on a queue, because every question waits for the author.

Where is the data allowed to live?

Metabase queries your database where it is. Self-hosted, the instance, its credentials and the network path are yours, and a read-only database user is the whole integration. The hosted option moves the instance to the vendor, at which point this question returns.

Power BI has two shapes. Import loads a copy into the dataset and refreshes on a schedule; a live-query mode pushes the query to the source at read time. A source behind a firewall reaches the cloud service through a gateway, an agent on a machine in your network that somebody keeps running and patched.

That is the honest form of the residency question: self-hosted Metabase keeps rows inside your network by construction, while Power BI can be arranged so rows stay local but keeps a copy by default. If a contract or a regulator says certain rows may not leave, that sentence chooses the tool before any feature does.

What are you maintaining in month six?

Metabase: the instance, which needs updates and backups; the database user's grants, which drift as the schema changes; the saved questions that break when a column is renamed — loudly, as an error on a card.

Power BI: the gateway, the refresh schedule, workspace membership, the desktop version the author installed, and the report that keeps showing the last successful refresh as though it were this morning. The breakage is quiet, which is worse.

The W3C's Data on the Web Best Practices treats versioning and quality as duties attached to a published dataset, which is what a refresh timestamp and a one-line definition are: the small local version of the same discipline.

How do permissions actually behave?

Metabase attaches permissions to data. A group is granted access to a database, a schema or a table, and row-level filtering and column masking exist on paid editions. The question asked is "may this group see this table?"

Power BI attaches them to the model and the workspace. Who may edit is workspace membership; what a viewer sees is computed when the report runs, with row-level security defined as roles and filters inside the dataset.

So a new Power BI report inherits enforcement without anyone remembering to set it, while a new Metabase question inherits the group's grant and nothing finer.

The comparison that decides it

Dimension	Metabase	Power BI
Who builds the report	Whoever has the question, in a browser	An author in the desktop app, publishing to readers
Where the rows sit	In your database, queried live	A copy in the dataset, refreshed, or a live query
What you maintain	The instance, its updates, a read-only database user	A gateway, refresh schedules, workspace membership
Permissions	Groups and table grants; row filters on paid editions	Roles inside the model, applied when the report runs
The exit	SQL and the schema travel; saved questions do not	The model does not travel; report files do
What to verify on the vendor's page	Which hosting, permission and embedding features your edition includes	Which refresh, gateway and licence limits apply to your case

How do you decide, in order?

1. Name the person who will build the first report somebody acts on. If the answer is "the boss, once", neither tool is the problem.
2. Name the second and third people who will ask a question next month. Several askers favour the browser; a single author favours the model.
3. Write the data constraint in one sentence: which tables may not leave, and where they stay.
4. Build one real question in each, on your data rather than the demo. Rename a column afterwards and watch what happens.
5. Read one chart back to the source system by hand and see whether the number survives the trip.
6. Decide who owns the tool in month six, by name, before signing.

Where this goes wrong

• The demo dataset. Both look decisive on a tidy sample. On real data one column holds three spellings of a customer, and the chart is wrong in a way nobody notices for months.
• A gateway nobody watches. It stops, the refresh fails, and the report keeps serving yesterday without saying so.
• Permissions copied from the org chart. A "managers" group that sees everything because that was easier than deciding.
• The author leaves. The model is undocumented, the measures carry a private shorthand, and the replacement starts again from the tables.

When neither fits

When the questions are the same set every month and the answer is a document somebody signs, a good spreadsheet and one careful person beat either product. And when there is no single source of the number, no tool fixes it: two systems that disagree will disagree inside a beautiful dashboard too. That belongs upstream — a warehouse, or one defined reporting table — and it is the first job, not the last.

What this advice leaves out

No prices here, deliberately. Both are sold per user on editions whose contents move, and a figure in an article would be wrong within a quarter and then repeated for years. Open the vendor's page for the edition you would actually buy, and read the last row of the table against it.

This also leaves out embedded analytics inside a customer-facing product, migrating reports that already exist, and the warehouse decisions underneath. We build and integrate reporting systems around tools like these; we resell neither product and take no commission, so the recommendation carries no commercial interest.

We build the definition of the number before the screen, because the licence is the cheap decision and the definition is the one that stays.