Forty online shops, forty domains, forty designs - and one Odoo behind all of them. That is not a trick: Odoo runs several websites out of the box. What nobody tells you is where the bill for it arrives.
What one instance buys you
One catalog, one warehouse, one list of orders. A product edited once shows up on every storefront that sells it, with the stock figure everyone else sees. A customer who ordered from two of the shops is one customer in the system, not two.
And one place to deploy. Forty separate installations mean forty updates, forty backups, forty sets of credentials and forty invoices every month. A change to the checkout is written once and lands on all of them at the same moment.
What each site keeps to itself
Domain, theme, menus, languages and prices belong to the site, not to the instance. Two shops on the same Odoo can look nothing alike and sell the same product at different prices in different currencies.
Content is scoped as well: pages, posts and products are tied to a website, and a visitor of one storefront never runs into the pages of another. The separation is a field on the record, which is exactly why it is cheap.
Where it bites: the workers
All forty sites share one pool of Odoo workers. A worker is a process, and it serves one request at a time. Forty storefronts do not get forty times the processes - they get the same pool that one storefront would.
So a heavy page on one shop is not that shop's private problem. While a worker spends eight seconds on a catalog search, it is not answering the other thirty-nine sites. Multiply that by the people who search all day and the pool is permanently busy.
That was the second reason to take the search out of the database, and not the size of the catalog alone: the search that took eight seconds was holding the workers of forty websites.
Odoo.sh or your own server
On Odoo.sh several websites work exactly as they should, and scaling and backups come without touching a server. What does not come is the right to run anything beside Odoo: no Redis of your own, no service of your own. Everything extra lives outside and is reached over the network.
On your own server with Enterprise the extra services sit in the same subnet as Odoo. Fewer hops, lower latency and full control over what runs there - in exchange for having to run it yourself.
When one instance is the wrong answer
When the businesses are genuinely unrelated: different companies, different accounting, people who must not see each other's orders. Odoo can separate that too, but the configuration gets heavy, and a mistake in one access rule is no longer a bug - it is a leak between businesses.
And when one of the shops is so much bigger than the rest that it has no business sharing a pool with them. Then it moves out. The rule is simple: one instance while the sites share data and people, separate instances when they share nothing but the owner.
And if the instance is not chosen yet, start one step earlier - with the price of Odoo, Salesforce, HubSpot and SAP for a team of ten.
Curious how the same systems behave day to day? Odoo in production: what holds, what breaks, what is not in the manual.