Many clients are not one company. They are a group: a holding entity with subsidiaries, or several brands, or one business operating across countries. Odoo can serve this two ways. One database, using Odoo's multi-company feature, where every entity is a company record inside a shared database. Or several databases, one per entity. The choice looks like a configuration detail at kickoff. It is closer to a foundation, because moving from one answer to the other later is a migration, not a setting change.
What one database with multi-company gives you
- Shared master data. One customer, one product catalogue, one chart-of-accounts template, visible across entities. A partner that deals with two subsidiaries is one record, not two.
- Native cross-entity reporting. Consolidated figures come from one query, because the data is in one place.
- Intercompany flows. A sale in one company generating a purchase in another is something the feature is built to handle.
- One system to operate. One backup, one upgrade, one set of users.
What separate databases give you
- Hard isolation. One entity's data is physically not in another's database. For a group whose entities have different owners, are being prepared for sale, or face regulatory data-residency rules, this is sometimes not a preference but a requirement.
- Independent lifecycles. One entity can upgrade, customise, or take downtime without touching the others.
- Contained blast radius. A bad migration or a corruption affects one entity, not the group.
The cost is the mirror image: every cross-entity question is now an integration. Consolidated reporting has to be built. Shared master data has to be synced. The things multi-company gave for free become projects.
The decision is about coupling, not size
The wrong way to decide is by counting entities. The right way is to ask how coupled the entities actually are. A group that operates as one business, with shared customers, shared products, and consolidated reporting as a daily need, wants one database; separating it would mean rebuilding integration for things that should be free. A set of genuinely independent entities that happen to share an owner, with different processes and little cross-entity traffic, wants separation; forcing them into one database couples things that have no reason to be coupled and makes every entity hostage to every other entity's changes.
Why it is hard to reverse
Going from one database to many means carving one schema's data apart along company lines, including shared records that now have to be duplicated. Going from many to one means merging schemas, reconciling id spaces, and resolving the same customer existing three times. Both are real migrations with real risk. That is why the decision deserves more than a kickoff afternoon: the cost of getting it wrong is not a reconfiguration, it is a project.
The note for the file
Ask one question before any other: are these entities one business wearing several legal hats, or several businesses sharing an owner. The honest answer to that, not the entity count, picks the architecture, and the architecture is expensive to change your mind about.