Odoo and Tableau

No official connector

Neither vendor ships one. Verified against the Odoo 19 source, there is no Tableau module in Community or Enterprise, so the routes are the same three available to any BI tool: the Odoo API, a read replica of the database, or a warehouse in between.

The decisions are largely shared with Power BI. What differs is that Tableau users tend to reach for a live database connection sooner, and that choice deserves its own attention.

Extract, do not connect live

A live connection points Tableau at the database and lets it query on demand. It sounds better and is usually the wrong choice.

Analytical queries are the shape a transactional database is worst at: wide scans, large aggregations, no useful index. Odoo's database is simultaneously serving people trying to confirm orders. One dashboard being refreshed by three people can visibly slow the application.

An extract materialises the data on Tableau's side. Dashboards are fast, the load on Odoo is one scheduled read instead of a query per interaction, and you control exactly when the data lands.

If you genuinely need live, point it at a read replica, never at production. That is the same rule as for any BI tool and it is the one most often ignored.

Odoo's schema is not analysis-shaped

This is the part that consumes the time, and it is not about connectivity at all.

Odoo normalises for an application. A sales figure involves orders, order lines, products, product templates, partners, currencies and taxes, joined through relations, with amounts that may be computed rather than stored.

Tableau wants a fact table and dimensions. Getting from one to the other means building a model: deciding what a row of your fact table represents, resolving the joins once rather than in every worksheet, and handling currency conversion deliberately.

Do that modelling once, in a view or a warehouse table, not repeatedly inside individual workbooks. The alternative is how two dashboards end up disagreeing: each author resolved the joins slightly differently and both look reasonable.

What direct SQL leaves behind

Reading the tables gives you the data without Odoo's meaning:

• Record rules and access rules are applied in Python, so SQL sees everything regardless of who is asking
• Multi-company scoping is a rule, not a column constraint, so a naive query sums entities that should never be summed
• Non-stored computed fields have no column at all, and stored ones are correct only while every write went through the ORM
• The schema changes between versions, so a workbook is an upgrade dependency nobody has documented

None of this makes the route wrong. It makes it a route where you own correctness, and where "the dashboard disagrees with Odoo" becomes a question you have to answer rather than one you can dismiss.

Reconcile before anyone trusts it

Pick a few figures with an unambiguous answer, revenue for a closed month, receivables at a date, unit volume for a product, and check them against Odoo's own report.

Do it when the dashboard is built and again after any Odoo upgrade. A number that has never been reconciled has never been verified, and a BI dashboard is believed far more readily than it is checked.

Security and access

Whatever credentials the connection uses can read what they are permitted to read, continuously and without a person present.

Give it a dedicated account with the narrowest access that works. Not an administrator, and not a shared login belonging to an employee who may leave. If the extract lands in a warehouse, the warehouse is now a copy of your business data with its own access model, and that model needs to exist deliberately rather than by default.