Odoo and Power BI

No official connector, three real routes

Verified against the Odoo 19 source, there is no Power BI module in either edition, and Microsoft does not publish an Odoo connector. So you assemble one of these.

The Odoo API. Read data the way any other client would, through the ORM. Access rules apply, computed fields resolve, and multi-company filtering works because you are inside Odoo's own logic. It is slower for large extracts and it is the correct default.

A read replica of the database. Direct SQL against a copy of PostgreSQL. Fast, flexible, and it reads the raw tables with none of Odoo's meaning applied.

An intermediate warehouse. Extract on a schedule into a warehouse and point Power BI at that. Most work to set up and the right answer once Odoo is one of several sources or the data volumes are serious.

What a direct database connection actually costs

This is the route people take because it is easy and fast, so it is worth being specific about what it skips.

Access rules and record rules do not exist in SQL. Odoo decides what a user can see in Python. Reading the tables directly returns everything, so a dashboard built this way can expose data the equivalent Odoo user could never open.

Multi-company filtering is gone. Odoo scopes records by company through its own rules. Raw SQL sees all companies at once, and a report that quietly sums two entities is wrong in a way that looks entirely plausible.

Non-stored computed fields do not exist as columns. Anything computed on read is simply absent, and anything stored is only correct while every write went through the ORM.

The schema is not a contract. Odoo changes tables between versions. A dashboard built on today's columns is an upgrade problem nobody remembers until it breaks.

If you take this route anyway, two rules: use a read replica, never production, because an analytics query can lock or slow the system people are working in. And accept that you are reimplementing business logic in SQL, so a figure that disagrees with Odoo's own report is now your problem to explain.

Where the API route struggles

The API is correct and it is not fast for bulk extraction. Pulling a million journal items through it is a poor use of everyone's afternoon.

The workable pattern is incremental: extract only what changed since the last run, filtering on write date, and accumulate. Full extracts stay for the initial load and for periodic reconciliation.

Note also that Odoo 19 deprecated the older RPC endpoints, /xmlrpc, /xmlrpc/2 and /jsonrpc, with removal scheduled for Odoo 22, in favour of a newer JSON endpoint using bearer-token authentication. Anything built now should target the current mechanism rather than the deprecated one, which is covered in the Odoo API.

Ask whether you need Power BI at all

Odoo has real reporting: pivot views, graph views, list grouping, saved filters and dashboards. For operational questions inside Odoo it is better than an external tool, because the data is live and already filtered by the rules that apply to the person looking.

Power BI earns its place in two situations. When you are combining Odoo with other sources, which is what it is genuinely good at. And when the audience will never log into Odoo, such as a board pack or an external stakeholder.

Building in Power BI what Odoo already answers is a common and expensive detour, and it usually surfaces as a dashboard that disagrees with the system for reasons nobody can trace.

Practical notes

Refresh on a schedule that matches the decision. Hourly refreshes on a report somebody reads monthly are pure load.

Model in the warehouse or in Power BI, not in the query. Ad hoc transformations buried in a data source are the reason two dashboards give two answers.

Reconcile against Odoo deliberately. Pick a few figures, revenue for a period, receivables total, and check them against Odoo's own report at least when the dashboard is built. A number that has never been reconciled has never been verified.

Watch security. Whatever credentials Power BI uses can read whatever they are allowed to read, continuously. Give it a dedicated account with the narrowest access that works, not an administrator, which is the principle covered in integration mistakes.

The same reasoning applies to Tableau, which differs in the tool rather than in any of the decisions above.