Which Odoo Subscription Should You Choose?

The Odoo pricing page reads as though you are choosing a version. What actually has to be settled are two independent questions: which features are available, and where the system runs. Together they determine what the system can do now and what it can be changed into later.

Moving between subscription tiers costs very little — it happens inside the same database, and features become available or unavailable immediately. What costs is discovering afterwards that the change requires a different database.

This guide does not quote prices. Odoo prices by region and adjusts over time; the configurator quote at signing is the only figure that applies.

1. Start With One Question

Do you need to install code modules?

A code module is written in Python and deployed into the system — whether purchased from a third party or developed to order.

• No — most of the hosting discussion below does not apply. What remains is whether the standard features cover your processes.
• Yes — the hosting options drop from four to two, and what remains is whether anyone can administer a server.

This question is decisive because both of Odoo’s shared-cloud hosting options do not expose the file system. There is no location to deploy code into. That is an architectural boundary, not a permission setting, and no pricing tier removes it.

2. Two Axes: Plan and Hosting

Odoo’s product structure is the intersection of two independent axes. Treating them as one is the main source of selection errors.

The first axis is the plan, which determines available features.

• Standard — no Studio, no external API access, no multi-company.
• Custom — Studio, multi-company and external API all available.

Code modules do not sit on this axis; hosting determines them. The two axes do intersect here, though: Standard is only available on shared cloud, and shared cloud cannot host code modules. Choosing Custom is therefore necessary for code modules, but not sufficient.

The second axis is hosting, which determines which server the system runs on.

1. Odoo Online (shared cloud) — multi-tenant; backups, security and upgrades handled by Odoo.
2. Odoo.sh — Odoo’s PaaS; code is pushed via Git, with staging environments included.
3. Self-hosting — your own server or VPS.

The Standard plan is only available on shared cloud. The Custom plan can be combined with any of the three.

One naming collision is worth noting: shared-cloud hosting under the Custom plan is officially called Standard Cloud Hosting, which is not the same thing as the Standard plan. The former carries the full Custom feature set; the only difference is that it runs on shared cloud and cannot host code modules.

2.1 Multiple Business Units: One Database or Several?

Where there are several business units or legal entities, this choice affects the subscription cost directly and therefore belongs in the selection stage.

How it is charged:

• One subscription covers one database. Enabling multi-company inside a single database does not increase the subscription cost as companies are added.
• Each additional database requires its own subscription, and the costs add up.
• Enabling multi-company on a Standard database triggers an upgrade to Custom.

How the two structures differ:

	Multi-company, one database	Separate databases
Subscription cost	One	One per database
Chart of accounts / products / contacts	Shared, or separated by company	Independent; cannot be shared
Consolidated reporting	Produced inside the system	Assembled outside the system
Data isolation	Depends on permission configuration	Physical
Blast radius of a failure	All companies	One business unit
Upgrades and maintenance	Once	Once per database

3. The Four Paid Combinations

	Online Standard	Custom + Standard Cloud Hosting	Custom + Odoo.sh	Custom + Self-hosting
Plan	Standard	Custom	Custom	Custom
Where the server is	Odoo cloud, multi-tenant	Odoo cloud, multi-tenant	Odoo PaaS	Your own server / VPS
Code modules	No	No (no file system access)	Yes, via Git	Yes
Studio	No	Yes	Yes	Yes
Multi-company	No	Yes	Yes	Yes
External API access	No	Yes	Yes	Yes
Who performs upgrades	Odoo	Odoo	Odoo platform, guided process	You
Backup / security / monitoring	Odoo	Odoo	Odoo platform	You
Licence tier	Lowest	Custom	Custom	Custom
Infrastructure cost	Included	Included	Billed by worker, storage, staging	Your own server
Data location	Determined by Odoo	Determined by Odoo	Within the Odoo cloud, limited regions	Your choice
root / system-level access	None	None	No root; system packages restricted	Full root

3.1 The Extension Path on Shared Cloud: the External API

Choosing shared-cloud hosting closes the code module route, but the external API unlocked by the Custom plan remains available. That approach runs the logic outside Odoo and reads and writes through the API, rather than deploying code into the system.

The external API is not specific to shared cloud — it works on Odoo.sh and self-hosting too, as a general extension architecture. What separates the two approaches is whether the logic needs to be inside the transaction:

• Preventing an operation from completing, appearing in the interface at the moment of entry, or participating in computed fields and validations — a module. An external program sits outside the transaction and can only react once the operation has finished.
• Data synchronisation, batch processing, reporting, integration with external systems — the external API fits, and it carries none of the module porting work that comes with a major-version upgrade.

Worth noting: the external API’s interface surface is Odoo’s data model. When a field is removed or a method signature changes, external programs break as well. What differs is where the break surfaces — a module fails while loading during the upgrade, where a staging environment will show it; an external program fails on its next call, which may happen while production is running.

4. What Actually Separates Self-hosting From Odoo Hosting

Under the Custom plan, the licence fee is charged per user and is the same across all three hosting options. The difference between self-hosting and Odoo hosting therefore does not appear in the licence line. It appears in three others:

1. Infrastructure cost — self-hosting means paying for a server and no longer paying Odoo.sh for workers, storage and staging.
2. Operational responsibility — backups, hardening, monitoring and upgrade execution move from the Odoo platform to you or your developer. On Odoo.sh these sit with the platform, alongside an official support channel.
3. Data location and system access — self-hosting allows you to determine where data is stored and how it is routed, with full root access and any system dependency you require. Odoo.sh provides no root access and a restricted set of system packages.

Self-hosting fits where data location is a defined requirement, or where non-standard system dependencies are needed, and where the capacity to administer a server exists. Organisations without that capacity need to establish who will carry the operational responsibility before choosing it.

5. Where Community Fits

Alongside the four paid options there is Community: open source, self-deployed, no licence fee.

Its boundaries:

• No Studio; configuration-level changes become development work
• No enterprise modules; the OCA community provides some alternatives
• No official support channel
• Every major-version upgrade is a separate paid development project
• Odoo maintains only the most recent major versions; earlier ones receive no security patches

Community fits where either of the following holds:

1. In-house IT that can carry the maintenance long term. Who takes over when that person leaves is part of the selection decision, not something to settle later.
2. No in-house IT, but no requirement to retain historical data and the capacity to absorb what a system failure costs. Data loss, downtime, defects that go unfixed and missing security patches are acceptable outcomes under that premise.

Where neither holds — nobody to carry the maintenance, and accounting entries, stock ledgers and customer history that need to remain queryable and reconcilable years later — the data risk belongs in the total cost comparison alongside the licence fee.

6. How Users Are Counted

• Internal users — anyone with a back-office login performing business operations. Charged per account, regardless of how often they log in.
• Portal users — external parties viewing their own documents (orders, quotations, invoices). They do not count as internal users and carry no cost.

Count the accounts that require a back-office login.

7. What Studio Is For

What Studio produces is stored in the database. It is data, not code. That has consequences:

1. It is not under version control. No change history, no code review.
2. Configuration points are scattered. A single requirement can touch fields, views, automated actions and access rights in four separate places. Changing it later means locating all of them first, and establishing what else each change affects.
3. Removal can leave residue. Each configuration point has to be found and deleted individually.
4. Its expressiveness is limited. Multi-step calculations, conditional branching and cross-model logic fall outside what Studio can express.

The same requirement built as a module keeps the logic in a small number of files, under version control, testable, and removable without residue.

The boundary: Studio suits lightweight, structurally simple configuration changes — adding a field, adjusting a view, configuring a reminder. Once a requirement acquires conditional branches or cross-model behaviour, a module is the appropriate form.

8. Who Pays for Upgrades

The “who performs upgrades” row above divides as follows:

• Upgrading the standard database — within the official service.
• Custom modules, Studio configuration and third-party modules — outside it.

Third-party modules are charged per version, and only if the author has released one for the target version. Where no release exists, you either take over maintenance or drop the feature.

The Odoo invoice is usually not the larger part of a major-version upgrade.

9. The Cost of Changing Databases

Changing subscription tiers happens inside one database and costs little. What costs is changing environment, changing database, migrating data.

1. There is no conversion script. Migration means exporting a backup and restoring it elsewhere. The database itself usually comes back up quickly.

2. Direction is asymmetric. Moving toward a less restricted environment (shared cloud → Odoo.sh → self-hosting) works, because the target does not block code modules. Moving toward a more restricted one fails if the source database contains any custom module at all.

3. The cost sits around the database, not in it. Once the restore completes:

   • The system URL has changed, so every outbound integration callback needs reconfiguring
   • Webhooks need re-registering and re-verifying on the other platform
   • API keys, mail servers and payment gateway credentials need resetting
   • Scheduled actions need checking that they resumed
   • Configuration held in external systems pointing at the old address has to be found item by item

   How much of this there is depends on how many integrations exist, and it has to be done while the business continues to run.

4. Enterprise to Community is one-way. Tables and columns created by enterprise modules do not fully disappear on uninstall, and what remains leaves a Community database in an indeterminate state. The usual approach in that direction is a new database configured from scratch, with historical data handled separately.

The question worth asking during selection is not whether something can be changed later, but whether changing it later requires a different database. If it does, it is expensive. If it does not, it is not.

10. Three Common Selection Errors

1. Choosing Custom, then pairing it with shared-cloud hosting, then finding that modules cannot be installed. Custom unlocks the features but shared cloud does not expose the file system. Where code modules are required, the options are Odoo.sh and self-hosting.

2. Choosing self-hosting to reduce the licence fee. All three Custom hosting options carry the same licence fee. Self-hosting reduces infrastructure cost and takes on the full operational responsibility.

3. Building complex business logic in Studio. Configuration proceeds quickly. The difference appears at modification time: scattered configuration points, no change history, and dependencies that have to be re-established from scratch.

11. Matching Situation to Option

Situation	Direction
Standard processes, no customisation, no IT staff	Online Standard
Studio / multi-company / API required, no code modules	Custom + Standard Cloud Hosting
Code modules required, no in-house server administration	Custom + Odoo.sh
Code modules required, administration available, data location matters	Custom + self-hosting
In-house IT able to carry maintenance long term; or no such capacity but able to absorb the cost of a system failure	Community, self-hosted

12. What This Guide Does Not Cover

Plan and hosting define the system’s capability and location. They say nothing about what goes into it. The first thing entered into a new database is master data — products, contacts, accounts, warehouses. Every business document exists by referencing it.

Configuration starts there, and so does the next question:

Once the user accounts exist, what can each person see by default?

Product cost and contact fields are visible to all internal users by default. That range follows from how Odoo references master data: master data carries the business rule set, and documents must read those fields to complete their calculations and validations, which pushes the readable range to its widest.

Whether that range matches the information boundaries your organisation actually operates with is something to confirm field by field.

(Next: What Are Your Staff’s Default Permissions in Odoo?)