Most reviews of Odoo are written either by someone who sells it or by someone who opened the demo for twenty minutes. This one is neither. Below are numbers from systems that run every day: a shop with a six-figure catalogue, forty storefronts on one instance, upgrades across versions with real data. Where something is bad, it says so.
What it carries without complaining
Size, first of all, is not the problem it is made out to be. A catalogue of a hundred and ten thousand products lives in Odoo without drama: the ORM holds it, the back office holds it, the warehouse holds it. Forty storefronts run on one instance - one database, one deploy, one place to patch - and that is the arrangement I would pick again, because the alternative is forty of everything.
Upgrades happen too. Versions 15 through 19 in production, sometimes two of them at once across different projects, because a client does not move just because a release came out. Data survives an upgrade. The part that does not survive by itself is your own code - and that is the honest price of customisation, not a defect.
Where it starts to stumble
What stops scaling first is search. Postgres full-text over a six-figure catalogue with filters and facets gets slower in a way no index fixes: at the worst point a search took eight seconds while the warehouse waited on the other side of the counter. Moving search out to Elasticsearch took it to one second - and that is a rewrite, not a setting.
The second thing is the front end. Odoo ships a website that assumes you might turn on a shop, a chat, a forum and an editor at any moment, and the browser pays for that assumption on every page. Even after cutting everything a landing page cannot possibly need, half a megabyte of compressed JavaScript still arrives on a page whose job is to show text.
It is deferred rather than blocking, so the first screen is fast if you do the work. But “deferred” is not “absent”: it is downloaded, parsed and executed on a phone with a weak processor too. On Core Web Vitals the difference between an Odoo site left as it comes and one that has been taken apart is the difference between a red score and a green one.
What an upgrade actually costs
An upgrade of a plain Odoo is a weekend. An upgrade of an Odoo with your own modules is a project, and the estimate depends on one thing: how much of what you built lives in code you control. Studio and clicked-together automations are the expensive part, because nobody can read them as a diff and nobody can test them before the button is pressed.
The pattern that works is dull. Every upgrade starts as a staging run on a copy of production data - the whole database, not a sample, because what breaks always breaks on the row nobody expected. Then the list of breakages is fixed in modules, not in the database. Then the same run is repeated until it is boring. Only then does the live system move.
Those three numbers are the shape of the systems these notes come from. They are not records - plenty of Odoo installations are bigger. They are the size at which the default settings stop being enough and every decision starts to have a price.
Four things that are not in the manual
Some things you only learn by losing a day to them. The rendered HTML of a website page is cached for an hour: you edit a record in the back office, the page does not change, and you go looking for a bug that is not there. The fix is one line that clears the template cache when your content changes - but you have to know the cache exists.
A constraint declared the old way, through _sql_constraints, is silently ignored in Odoo 19: the module installs, the log is clean, and the database has no constraint at all. Duplicates arrive later, quietly. A script added to the frontend bundle may never run, because it lands in the lazy bundle that arrives after DOMContentLoaded - the event your listener is waiting for has already happened.
And a module can be in the list, described in the documentation, and still refuse to install: Enterprise modules appear in Community as stubs marked uninstallable. Appointments is one of them, which is why the booking page on this site is a module of my own rather than a setting.
Support, and what replaces it
The support is the part I would change first. When the problem is on Odoo’s side, you wait - and you wait with evidence: logs, measurements, the same question asked three times. On one project a platform rate limit made Googlebot collect 429s for months while shops fell out of the index; it took three rounds to get the limits raised. That story is written up in more detail elsewhere, and it is the fairest complaint there is against Odoo.
What saves the same year is the other half of the same system: nobody has to approve your architecture. Search moved to Elasticsearch because I decided it should. The front end is thin because I took it apart. The booking page exists because the module was written in an afternoon. In a closed system every one of those is a ticket; here they are a commit.
Who it fits and who it does not
Odoo fits you if what you need is one system for the whole company and you have - or can hire - someone who writes code. It fits badly if you want everything to work out of the box and never be touched: that is not what an open platform gives you. Consolidated reporting across a dozen legal entities, certified industry verticals, a tender that requires a vendor from a Gartner quadrant - those are not its fights.
If you are weighing it up right now, the useful thing is not another review. It is half an hour with your own screen and your own numbers: what is slow, what is stuck, what it would cost to change. That half hour is free, and at the end of it I will say honestly whether the task is mine.
Choosing who does the work, not just what to run? Odoo partner or independent developer: what the difference actually is.