Multiple Odoo databases on one server

Multi-company or multiple databases?

Odoo offers two ways to handle more than one company, and they solve different problems.

Multi-company: one database, several companies

In a single database, Odoo can hold several companies. Users can switch between the companies they have access to, and records such as products, contacts and journals can be shared or kept per company. Odoo's multi-company documentation also describes settings for inter-company transactions, where an order in one company creates the matching document in the other; check which of these features your edition includes.

Multi-company suits a group of related companies that:

• share products, customers or suppliers;
• trade with each other and want documents created automatically;
• want consolidated reporting across the group;
• have the same people working in several of them.

Multiple databases: fully separate Odoos

Separate databases share nothing. Each has its own users, settings, installed modules and data. This suits:

• unrelated businesses, or clients of an Odoo partner;
• companies that must not see each other's data at all;
• companies that need different modules or customisations;
• test, training or staging copies of production.

Choosing wrong is expensive to undo: merging two databases into one, or splitting one into two, is a data migration project. Decide early, and when in doubt about companies that might be sold or separated one day, keep them apart.

Two ways to run multiple Odoo databases on one server

One Odoo process serving several databases

A single Odoo installation can serve several databases. Each request is routed to a database, and the dbfilter option decides which databases a request can see. Odoo's deployment documentation explains that dbfilter can use the hostname (%h) or the first part of it (%d), so erp.client-a.com sees only its own database. It also says that on servers hosting several databases in production, dbfilter must be set for some features to work correctly.

This is economical, but everything is shared: the same workers, the same Odoo version, the same addons path and the same configuration. A heavy report in one database slows the others, and a restart for one restarts all.

One Odoo process per database

The alternative is a separate Odoo service per database, each with its own configuration file, port, workers and system user, behind the same Nginx and the same PostgreSQL server. Each service has a dbfilter that matches only its own database.

This costs some extra memory, but each database:

• can be restarted, tuned and updated on its own;
• can have its own modules on its own addons path;
• cannot read another database's files if each runs as its own user;
• has its own log, so problems are easier to trace.

For production databases that belong to different companies or clients, this is usually the better choice.

Sizing a server for several Odoo databases

Count the workers for every database together: each Odoo process needs its own workers and cron threads, and they all share the server's CPU and RAM with PostgreSQL. Start from each database's expected users, add them up, and size with the Odoo server sizing guide.

Two limits are easy to forget:

• Database connections. Every Odoo process opens its own pool of connections. Add them up and keep the total under PostgreSQL's max_connections. See PostgreSQL tuning for Odoo.
• Disk. Each database has its own filestore and backups. Plan disk space for all of them, plus room to restore one.

Security for multiple Odoo databases

• Turn off the database manager with list_db = False, so nobody can list, copy or delete databases from the web.
• Use dbfilter so each domain can only reach its own database.
• Give each Odoo process its own system user and PostgreSQL role, without superuser rights.
• Use separate admin passwords for each database, and a different master password for each configuration.

Our Odoo server hardening checklist covers the rest.

Test and training databases next to production

The most common second database is a copy of production for testing or training. It is useful, but it needs a few precautions:

• Neutralize it. A copy of production contains real email addresses, scheduled actions and integration settings. Run Odoo's neutralize step so it cannot email customers or run production jobs.
• Give it its own domain, clearly different from production, so nobody enters real orders on it by mistake.
• Limit its resources, so heavy tests do not slow production down. Fewer workers are usually enough.

Our article on why every Odoo project needs a staging environment explains the rest.

Backups and upgrades with several databases

Back up each database and its filestore separately, so you can restore one without touching the others. Major upgrades are also per database: each one is migrated on its own, and with one shared Odoo process they all have to move to the new version at the same time. Separate processes, or separate servers per Odoo version, let you upgrade one database at a time.

Multiple Odoo databases on CloudPilot

On CloudPilot, each instance is a separate Odoo database and process:

• Its own service, user and database role. Each instance runs as its own systemd service and system user, with its own PostgreSQL role, and can only write to its own data directories.
• Its own configuration. Each instance has its own odoo.conf with a dbfilter for its database and the database manager turned off. Workers and limits can be changed per instance.
• Its own domains, backups, staging and modules. Restore, upgrade or deploy to one instance without touching the others.
• One Odoo version per server. Instances on a server share its Odoo version and PostgreSQL. Add a server for another version.

Pro and Business include unlimited instances. See managed Odoo hosting for what CloudPilot looks after, Create an Odoo instance for the steps and pricing for each plan.

Multiple Odoo databases: questions