Odoo Multi-Tenant Architecture — Run Multiple Instances Efficiently

Multi-tenancy in the Odoo world means running multiple separate Odoo databases or instances on shared infrastructure. Every tenant — whether that is a client company, a business unit, or a SaaS customer — gets their own data, users, and configuration. The question is how you isolate them.

Odoo was not originally designed as a multi-tenant SaaS platform the way, say, Salesforce was. It started as a single-database ERP. But the community and companies building on Odoo have developed several patterns that work well in production. We have seen all three approaches running at scale across hundreds of deployments managed through OEC.sh's multi-tenant platform.

What Is Multi-Tenancy in Odoo?

Multi-tenancy means serving multiple independent customers (tenants) from shared infrastructure. In the Odoo context, each tenant typically needs their own database — Odoo stores everything in PostgreSQL, including module configurations, business data, and user accounts. Two tenants cannot share a single Odoo database without seeing each other's data.

This is different from Odoo's built-in multi-company feature, which lets you create multiple companies inside one database with record-level access rules. Multi-company works for related business entities under the same organization, but it is not suitable for unrelated tenants because all companies share the same module set, the same Odoo version, and the same admin user pool. If Client A needs Odoo 18 and Client B is still on Odoo 17, multi-company will not work.

True multi-tenancy requires one of three approaches, each with a different isolation level:

Architecture Options Compared

Each approach sits at a different point on the isolation-vs-efficiency spectrum. Here is a detailed breakdown.

Option A: Shared Database with dbfilter

Odoo has a built-in mechanism for multi-database operation. You run a single Odoo server process that connects to a PostgreSQL instance containing multiple databases. The --db-filter parameter routes incoming requests to the correct database based on the hostname. For example, client-a.yoursaas.com hits database client_a while client-b.yoursaas.com hits client_b.

  ┌──────────────────────────────────────────┐
  │              Nginx / Reverse Proxy        │
  │   client-a.saas.com  client-b.saas.com   │
  └─────────────────┬────────────────────────┘
                    │
  ┌─────────────────▼────────────────────────┐
  │         Single Odoo Process              │
  │   --db-filter=^%h$  (hostname routing)   │
  │   Workers: 4-8  |  RAM: ~1.2 GB          │
  └─────────────────┬────────────────────────┘
                    │
  ┌─────────────────▼────────────────────────┐
  │            PostgreSQL                     │
  │   ┌──────────┐  ┌──────────┐  ┌────────┐│
  │   │client_a  │  │client_b  │  │client_c││
  │   │ database │  │ database │  │database ││
  │   └──────────┘  └──────────┘  └────────┘│
  └──────────────────────────────────────────┘

When to use it: Internal multi-company setups, dev/staging environments, or very small SaaS operations where all tenants are on the same Odoo version with the same modules. Not recommended when tenants have different SLA requirements or need independent update schedules.

Option B: Isolated Instances

Each tenant gets their own Odoo process running on a different port, with their own PostgreSQL database. A reverse proxy (Nginx, Caddy, or Traefik) routes traffic based on the hostname to the correct Odoo port. Each instance can run a different Odoo version, install different modules, and be restarted independently.

  ┌──────────────────────────────────────────┐
  │              Nginx / Reverse Proxy        │
  │   client-a.com → :8069                   │
  │   client-b.com → :8070                   │
  │   client-c.com → :8071                   │
  └──┬──────────────┬──────────────┬─────────┘
     │              │              │
  ┌──▼─────┐   ┌───▼────┐   ┌───▼────┐
  │ Odoo   │   │ Odoo   │   │ Odoo   │
  │ v18    │   │ v17    │   │ v18    │
  │ :8069  │   │ :8070  │   │ :8071  │
  └──┬─────┘   └───┬────┘   └───┬────┘
     │              │              │
  ┌──▼─────┐   ┌───▼────┐   ┌───▼────┐
  │client_a│   │client_b│   │client_c│
  │  (PG)  │   │  (PG)  │   │  (PG)  │
  └────────┘   └────────┘   └────────┘

When to use it: Agencies managing 5-30 client installations where clients need different Odoo versions or module sets. This is the approach most Odoo consulting firms use because it provides strong isolation without the complexity of container orchestration.

Option C: Container-Based (Docker / Kubernetes)

Each tenant runs inside their own Docker container (or Kubernetes pod) with Odoo and optionally their own PostgreSQL instance. A reverse proxy like Traefik or an Ingress controller routes traffic. Container orchestration handles resource limits, health checks, restarts, and scaling.

  ┌──────────────────────────────────────────┐
  │       Traefik / Ingress Controller        │
  │    Automatic SSL  |  Host-based routing   │
  └──┬──────────────┬──────────────┬─────────┘
     │              │              │
  ┌──▼───────────┐ ┌▼────────────┐ ┌▼───────────┐
  │ Container A  │ │Container B  │ │Container C  │
  │ ┌──────────┐ │ │┌──────────┐ │ │┌──────────┐ │
  │ │ Odoo v18 │ │ ││ Odoo v17 │ │ ││ Odoo v18 │ │
  │ └────┬─────┘ │ │└────┬─────┘ │ │└────┬─────┘ │
  │ ┌────▼─────┐ │ │┌────▼─────┐ │ │┌────▼─────┐ │
  │ │ PG (own) │ │ ││ PG (own) │ │ ││ PG (own) │ │
  │ └──────────┘ │ │└──────────┘ │ │└──────────┘ │
  │ CPU: 2 cores │ │CPU: 1 core  │ │CPU: 4 cores │
  │ RAM: 2 GB    │ │RAM: 1 GB    │ │RAM: 4 GB    │
  └──────────────┘ └─────────────┘ └─────────────┘

When to use it: SaaS providers running 30+ tenants who need strict resource isolation and automated scaling. Also the right choice when you have a DevOps team comfortable with container orchestration. Overkill for agencies managing fewer than 10 clients.

Quick Comparison

Security Considerations

Multi-tenancy introduces security concerns that do not exist in single-tenant deployments. When multiple clients share infrastructure, you need to guarantee that Tenant A can never access Tenant B's data — not through the UI, not through the API, and not through the filesystem.

Performance Planning

Multi-tenant Odoo deployments fail most often on resource planning. A server that runs one Odoo instance comfortably can grind to a halt when you add ten more without accounting for memory, CPU, and database connection overhead. Here is how to plan correctly.

Memory Budgeting

Each Odoo worker process consumes 150-200 MB of RAM under typical load. A minimal production setup with 2 workers per instance uses 300-400 MB. Add PostgreSQL shared buffers (25% of RAM is a common starting point) and OS overhead, and you get this baseline:

  Total RAM:                    16,384 MB
  ─────────────────────────────────────────
  OS + system services:          1,024 MB
  PostgreSQL shared_buffers:     4,096 MB  (25% of RAM)
  PostgreSQL connections:          512 MB  (~10 MB x 50 connections)
  ─────────────────────────────────────────
  Available for Odoo:           10,752 MB

  Per instance (2 workers):        400 MB
  ─────────────────────────────────────────
  Max instances:          10,752 / 400 ≈ 26

  With safety margin (80%):        ~20 instances
  With cron workers (+1 per):      ~15 instances

These numbers assume light workloads (5-10 active users per tenant). For tenants with 20+ active users, budget 4 workers per instance and cut the instance count in half. Use the OEC.sh server calculator to model your specific setup.

Shared PostgreSQL vs Dedicated

In most multi-tenant setups, all Odoo instances share a single PostgreSQL server. This works well up to 20-30 tenants on a 16 GB server. Beyond that, PostgreSQL becomes the bottleneck — not on CPU but on connection count and shared buffer contention.

Each Odoo worker opens one PostgreSQL connection. With 15 instances running 2 workers each plus 1 cron worker, you need at least 45 connections. Add connection pooling with PgBouncer to multiplex these efficiently:

  [pgbouncer]
  pool_mode = transaction          # Best for Odoo
  max_client_conn = 200            # Total from all Odoo instances
  default_pool_size = 20           # Connections to PostgreSQL
  reserve_pool_size = 5            # Overflow buffer
  reserve_pool_timeout = 3         # Seconds before using reserve

  # Per-database overrides
  [databases]
  client_a = host=127.0.0.1 dbname=client_a pool_size=5
  client_b = host=127.0.0.1 dbname=client_b pool_size=5
  client_c = host=127.0.0.1 dbname=client_c pool_size=3

PgBouncer in transaction pooling mode can reduce your actual PostgreSQL connections by 3-5x, which is critical for multi-tenant setups where connection exhaustion is the most common cause of outages.

CPU Allocation

Odoo is mostly I/O-bound (waiting on PostgreSQL), so CPU usually is not the first bottleneck. A 4-core server can typically handle 8-12 Odoo workers across multiple instances without saturation. The exception is heavy reporting or data-intensive operations — if one tenant runs a large stock valuation report, it can consume a full core for several seconds.

For container setups, set CPU limits per container to prevent one tenant from monopolizing the host. For isolated instances, use cgroups or systemd resource controls.

How OEC.sh Handles Multi-Tenancy

OEC.sh uses the isolated instance approach with additional automation layered on top. When you deploy through OEC.sh, each Odoo project on a server gets:

The Agency plan supports unlimited projects per server, which makes it the natural fit for consultancies and SaaS providers running multi-tenant Odoo. You bring your own cloud server (AWS, Hetzner, DigitalOcean, or any provider), and OEC.sh handles the deployment, isolation, and management. You keep full control of your infrastructure and your clients' data.

This avoids the shared-failure-domain problem of dbfilter mode while keeping operational overhead much lower than managing your own Kubernetes cluster. For most agencies, it hits the sweet spot.

Billing Models for Odoo SaaS

If you are building a SaaS product on Odoo or reselling Odoo deployments, you need a billing model that covers your infrastructure costs while staying competitive. Here are the four models we see in practice:

Our recommendation: Start with per-database pricing. It is the simplest to implement, easiest for customers to understand, and maps directly to your infrastructure costs (one Odoo instance = one set of resources). As you scale, layer in user-based pricing tiers for larger clients. Avoid pure resource-based pricing unless your customers are technically sophisticated.

To keep your margins healthy, use the server calculator to estimate your per-tenant infrastructure cost, then price at 3-5x that cost. For example, if a single Odoo instance on Hetzner costs you about $5/month in server resources, charge $25-49/month for a managed deployment. That leaves room for support, backups, monitoring, and profit. Check our cloud provider comparison for detailed cost breakdowns.

Frequently Asked Questions