VPS Hosting Architecture for Odoo and ERPNext: CPU, RAM, PostgreSQL and Backups

Why VPS Architecture Matters So Much for Odoo and ERPNext

Odoo and ERPNext look simple from the user side: open the browser, log in, manage sales, stocks, projects and accounting. Under the hood, though, they are heavy, long‑lived web applications that constantly talk to PostgreSQL, keep many Python worker processes alive and run background jobs all day. That is why the way you design your VPS hosting architecture matters more here than for a basic website.

In this article, we will walk through a practical architecture for Odoo and ERPNext on a VPS: how many vCPUs and how much RAM you should plan, what PostgreSQL layout and tuning makes sense, and how to build a backup strategy you can trust when something goes wrong. We will use examples from real‑world deployments we manage at dchost.com and connect them to clear rules of thumb, so you can either validate your current setup or design a new one with confidence.

If you are already familiar with worker counts and reverse proxy settings, you can also read our more operational guide, VPS hosting settings for Odoo and ERPNext (CPU, RAM, workers and reverse proxy). Here we will stay one level higher: overall VPS sizing, PostgreSQL architecture and backup strategy.

Mapping Odoo/ERPNext Workloads to CPU and RAM on a VPS

Both Odoo and ERPNext are multi‑module ERP platforms built on Python and PostgreSQL. They keep multiple worker processes and background tasks alive, and often serve dozens of concurrent users who keep sessions open for hours. Understanding how these workloads translate to CPU and RAM usage is the first step to a stable VPS architecture.

The main resource consumers in Odoo and ERPNext

On a typical production instance you will see four main resource types:

• Web workers: Gunicorn or similar workers that handle HTTP requests. Each worker consumes RAM and some CPU.
• Long‑polling / real‑time workers: Used for notifications, chat and live updates. They keep connections open and use RAM steadily.
• Background jobs: Scheduled tasks (cron jobs), email sending, report generation, integrations with other systems.
• PostgreSQL queries: Each connected session consumes memory and CPU for query execution, especially when reports or large exports run.

This means you rarely hit a pure CPU bottleneck first. More often, deployments start to struggle because of RAM pressure (swapping, OOM killer) or database contention (slow queries, locks) before CPU reaches 100%.

Starter, growing and large instances: realistic sizing

Exact numbers always depend on custom modules, integrations and user behaviour, but you can use the following as a practical starting point for a single Odoo or ERPNext production instance on a quality VPS (for example, NVMe‑backed VPS plans at dchost.com):

• Small team (up to ~15 active users)
  2 vCPU, 4–6 GB RAM, fast NVMe disk, PostgreSQL on the same VPS. 2–4 web workers, minimal background jobs. Suitable for early deployments or pilot projects.
• Growing business (15–60 active users)
  4 vCPU, 8–12 GB RAM. PostgreSQL can still live on the same VPS if tuned properly, but we often recommend planning for a separate database VPS as the next step. 4–8 web workers, dedicated background worker(s).
• Larger deployment (60–200 active users or heavy reporting)
  8+ vCPU, 16–32 GB RAM across two VPS servers: one for Odoo/ERPNext application, one for PostgreSQL. Connection pooling becomes essential, and storage performance (IOPS, latency) starts to matter as much as CPU/RAM.

For very small installations, it is tempting to run with 2 GB RAM. Our experience says that is only comfortable for test/staging, not for production. Once you enable a few modules and background jobs, you will have little headroom. If your budget is tight, use 4 GB as the absolute minimum for production and be disciplined with workers.

Practical CPU and RAM rules of thumb

When we size VPS plans for Odoo and ERPNext at dchost.com, we use a few simple rules:

• 1–1.5 GB RAM per Python worker process (including web and long‑polling). This is conservative but safe for real‑world modules and customisations.
• Leave at least 2 GB RAM for PostgreSQL and OS on any single‑VPS setup. If you cannot, reduce worker counts until you can.
• vCPUs ≈ number of simultaneous workers actually doing work. If you have 4 workers but only 2 vCPUs, under high load they will fight for CPU time. Some over‑commit is fine, but not 4–5x.
• Plan headroom: keep ~30% CPU and RAM free during normal office hours. ERP load is spiky (batch imports, reporting, end‑of‑month accounting).

For more general VPS sizing logic, you may also like our article how many vCPUs and how much RAM do you really need. The mindset there is the same: avoid overpaying for unused cores, but do not run at 95% utilisation all day either.

PostgreSQL Architecture for Odoo and ERPNext

Both Odoo and ERPNext rely heavily on PostgreSQL. Slow or unstable databases usually hurt more than any CPU shortage. A good VPS architecture must therefore treat PostgreSQL as a first‑class citizen: right placement, right resources and right configuration.

One VPS or separate database VPS?

There are three common patterns we see in real deployments:

• Single VPS: app + PostgreSQL + reverse proxy
  Best for small teams and early phases. Simpler to manage, easier backups, fewer moving parts. Ensure enough RAM and disk IOPS.
• Two VPS: app server and separate PostgreSQL server
  Right choice when database CPU or RAM usage starts to compete with the application. Enables independent scaling (more RAM for DB, more CPU for app) and isolates noisy processes.
• PostgreSQL on a dedicated server or colocation box
  For very heavy instances (large manufacturing, multi‑company setups) a dedicated PostgreSQL host with lots of RAM and fast NVMe can be more cost‑effective than many small VPS nodes. dchost.com also offers dedicated servers and colocation for these cases.

Our rule of thumb: up to roughly 30–40 active users and modest reporting, a well‑tuned single VPS is fine. Beyond that, or if you have many background integrations, it is usually time to move PostgreSQL to its own VPS and introduce connection pooling.

Key PostgreSQL settings for ERP workloads

We will not list every possible parameter, but a few have outsized impact for Odoo and ERPNext:

• shared_buffers: Often set to 20–25% of system RAM (on the DB server). For example, 2–4 GB on a VPS with 16 GB RAM. Too low and PostgreSQL hits disk more often; too high and you starve the OS cache.
• effective_cache_size: Roughly 50–75% of RAM. This tells the planner how much data is likely cached (PostgreSQL and OS combined) and influences index vs sequential scan decisions.
• work_mem: Memory per sort/aggregate operation. For ERP workloads, start low (e.g. 16–32 MB) and increase carefully for reporting‑heavy deployments. Remember this is per operation, not global.
• max_connections: Do not simply set this to a huge number. Too many concurrent backend processes waste RAM. With connection pooling (see below), a limit in the hundreds is usually enough.
• WAL settings: Parameters like wal_level, checkpoint_timeout and max_wal_size impact write performance and backup options. For Odoo/ERPNext, wal_level=replica is a sensible default when you plan continuous archiving or replication.

We wrote a full PostgreSQL performance playbook for VPS environments, including these settings, in our article the friendly VPS playbook for PostgreSQL performance. It is not Odoo‑specific, but the same tuning principles apply.

Connection pooling with PgBouncer

Odoo and ERPNext open many database connections, especially when you scale worker counts. Each PostgreSQL backend process consumes memory even when idle. On a VPS with limited RAM, this alone can cause memory pressure and context‑switch overhead.

Running PgBouncer in front of PostgreSQL (often on the same VPS as the DB) solves two issues:

• It limits the number of actual PostgreSQL backends while allowing many logical app connections.
• It reuses established connections, reducing the cost of creating and tearing down DB sessions.

For Odoo/ERPNext, we typically use pool_mode=session or transaction depending on the exact version and modules involved. Pool size should reflect how much RAM you can dedicate to active PostgreSQL backends without starving the OS. Combined with reasonable work_mem and max_connections, PgBouncer often produces a more stable experience than simply adding more RAM.

Autovacuum and table bloat

ERP systems generate a constant stream of small writes: new records, updates, deletes, log entries. PostgreSQL’s autovacuum is what keeps dead tuples under control and indexes from growing endlessly. Misconfigured autovacuum eventually leads to performance degradation.

On VPS deployments, we recommend:

• Leaving autovacuum ON, but tuning thresholds and cost limits so it can keep up during office hours without overloading the server.
• Scheduling occasional VACUUM (FULL) or pg_repack for the largest, most updated tables during maintenance windows.
• Monitoring table and index sizes over time, so you can catch bloat before it becomes a fire.

We explain this topic in detail, with concrete parameter examples, in our guide to PostgreSQL autovacuum tuning and bloat control on a VPS.

Memory, Swap and Stability for Long‑Lived ERP Sessions

ERP users tend to keep browser tabs open all day, run big filters, export spreadsheets and open several modules in parallel. That is why a calm Odoo/ERPNext system depends heavily on predictable memory behaviour. On a VPS, when RAM runs out, the OS starts using swap or invokes the OOM killer, which might terminate PostgreSQL or app workers.

Designing RAM and swap behaviour

A few practical guidelines we apply on VPS deployments at dchost.com:

• Always enable swap, but do not rely on it for normal operation. Swap is a safety net, not extra RAM.
• On small VPS (4–8 GB RAM), a swap size of 1–2x RAM is usually reasonable. On larger instances, you can keep swap smaller (e.g. 16 GB) as a buffer.
• Tune PostgreSQL and worker counts so that under normal business load, swap usage stays near zero. Growing swap usage during the day is a smell.
• Set alerts on memory usage and swap activity. It is cheaper to add RAM or move PostgreSQL to a separate VPS than to debug random OOM kills later.

We have a dedicated article, managing RAM, swap and the OOM killer on VPS servers, where we go deeper into vm.swappiness, swap file vs swap partition and monitoring patterns. The same principles keep Odoo/ERPNext stable during peak hours.

Common ERP memory anti‑patterns

When we perform architecture reviews, we often see the same recurring issues:

• Too many workers on too little RAM: People copy‑paste a configuration for 8 workers from a bigger server onto a 4 GB VPS. It runs fine with 3 users, then falls apart with 20.
• PostgreSQL sized as if it owned the whole machine: shared_buffers set to several GB on a small VPS where Odoo, Nginx and other services also live.
• No resource isolation: Extra services (mail server, monitoring agents, other apps) installed on the same VPS eating RAM behind the scenes.

The cure is simple: measure real usage with tools like htop, review peak patterns and rebalance workers and PostgreSQL memory. If you keep fighting RAM even after optimisation, it is time to upgrade the VPS plan or split app and database to two servers.

Backup Strategy for Odoo/ERPNext Databases and Files

Having a solid VPS and PostgreSQL configuration is only half the story. ERP platforms contain your core business data: invoices, stock movements, HR records, CRM history. A good hosting architecture must include a tested backup and restore strategy, not just a cron job running blindly.

Start from RPO and RTO, not from tools

Before choosing tools, define two key numbers with your business stakeholders:

• RPO (Recovery Point Objective): How much data loss (in minutes or hours) is acceptable after an incident? For example, is losing the last 4 hours of entries tolerable, or must it be under 15 minutes?
• RTO (Recovery Time Objective): How long can the system be down while you restore? 1 hour, 4 hours, a full day?

These answers drive how often you back up PostgreSQL, whether you keep continuous WAL archives and what restore procedure you practice. For a deeper discussion of RPO/RTO and planning, see our article how to design a backup strategy.

What to back up for Odoo and ERPNext

At minimum, you should protect:

• PostgreSQL database(s): The main ERP database plus any extra ones you may use for staging or add‑on services.
• Filestore / attachments: Odoo and ERPNext store file uploads on disk (e.g. filestore/ directory). Losing these breaks documents, images and some reports.
• Configuration and custom code: Config files, installed modules, custom add‑ons. Often stored in Git, but your backup should cover them too.

On a single VPS deployment, this usually means filesystem paths for PostgreSQL data directory, filestore directories and configuration under /etc/ plus your application install path.

Logical vs physical backups and point‑in‑time recovery

We generally mix two types of PostgreSQL backups:

• Logical backups (pg_dump)
  Produce SQL or custom dump files per database. Easy to restore on a different PostgreSQL version or server. Good for nightly backups and for taking pre‑migration snapshots.
• Physical backups (pg_basebackup or backup tools like pgBackRest)
  Create a binary copy of the data directory plus WAL (Write‑Ahead Log) files for continuous archiving. Combined with WAL retention, this allows point‑in‑time recovery (PITR), meaning you can restore the database to an exact moment (e.g. just before a batch import went wrong).

For Odoo and ERPNext, our standard pattern is:

• Nightly logical backups for each production database.
• Continuous WAL archiving plus daily physical base backups for fast restore and PITR.
• Retention policies that keep several recent days on fast storage and older backups on cheaper object storage.

If you want to go deeper into PostgreSQL backup tooling, we also describe a calm PITR workflow in our article about PostgreSQL backup and PITR with pgBackRest on a VPS.

3‑2‑1 rule, off‑site copies and ransomware resistance

A single backup copy on the same VPS is not a backup strategy. It is just another file that can be deleted, encrypted by ransomware or lost with a broken disk. We recommend following the classic 3‑2‑1 rule:

• 3 copies of your data (production + two backup copies).
• 2 different media (for example, local VPS disk + remote object storage).
• 1 copy off‑site (in a different data centre or region).

Modern object storage with versioning and immutability gives you extra protection. With object lock and write‑once policies, even if an attacker compromises the VPS, they cannot simply delete or overwrite historical backups in your off‑site bucket.

We cover this topic in detail in our ransomware‑resistant hosting backup strategy guide, including immutable backups and real air‑gap techniques.

Backup encryption, keys and restore drills

ERP data is sensitive. Your architecture should treat backups as production data from a security perspective:

• Encrypt backups at rest with strong keys. Protect both on‑VPS archives and off‑site copies.
• Store encryption keys and passwords in a separate secrets management system, not on the same VPS without protection.
• Test restores regularly: automate a weekly or monthly restore into a staging VPS to verify that dumps are valid and procedures are documented.
• Document a simple restore runbook so that more than one person on your team can execute it under pressure.

A backup that has never been restored is a hope, not a plan. Plan time for actual restore drills as part of your VPS architecture lifecycle.

Example VPS Architectures for Odoo and ERPNext on dchost.com

To make all of this concrete, here are three architectures we commonly deploy for Odoo and ERPNext on dchost.com infrastructure. Treat them as templates that you can adapt based on your modules and traffic.

1. All‑in‑one VPS for small teams

• VPS: 4 vCPU, 8 GB RAM, fast NVMe storage.
• Services: Nginx/Apache reverse proxy, Odoo/ERPNext app, PostgreSQL, PgBouncer, local backup scripts.
• Use case: Up to ~30 concurrent users, limited heavy reporting, few external integrations.

Backups run locally to a compressed directory, then synchronise to off‑site object storage. Monitoring tracks CPU, RAM, disk I/O, PostgreSQL slow queries and backup status. When CPU/RAM usage trends upwards or reports become slow, we scale vertically (more RAM) or prepare a migration to the two‑VPS architecture.

2. Split app and database across two VPS

• App VPS: 4–8 vCPU, 8–16 GB RAM. Hosts Nginx, Odoo/ERPNext, long‑polling and background workers.
• DB VPS: 4–8 vCPU, 16–32 GB RAM. Hosts PostgreSQL, PgBouncer, backup tooling.
• Use case: 30–150 active users, multiple companies, heavier reporting, integrations with external systems.

This layout isolates the database from application spikes. You can tune PostgreSQL more aggressively, allocate more RAM to shared_buffers and cache, and still keep the OS comfortable. Network latency between the two VPS is low because they live in the same data centre. Backups and PITR configuration run on the DB VPS and push encrypted archives to off‑site storage.

3. High‑availability direction with replication

When uptime requirements are strict, we add replication to the mix:

• Primary PostgreSQL VPS handling writes.
• Replica PostgreSQL VPS receiving WAL via streaming replication.
• Optionally, a read‑only Odoo/ERPNext instance or reporting tools pointing at the replica for heavy reports.

This does not automatically give you zero downtime (you still need failover orchestration), but it significantly reduces RTO and helps offload heavy read‑only traffic. We discuss replication patterns and failover concepts more generally in our guide to MySQL and PostgreSQL replication on VPS for high availability.

In some cases, it is more economical to host the primary database on a dedicated server or colocation machine and keep application nodes as VPS. dchost.com offers all three options (VPS, dedicated, colocation), so we can design a hybrid architecture when needed.

Monitoring, Maintenance and Growth Planning

A good VPS architecture for Odoo and ERPNext is not set‑and‑forget. Usage patterns evolve, new modules get installed and databases grow. To stay ahead of problems, you should build monitoring and maintenance into the design from day one.

What to monitor

At minimum, we recommend monitoring:

• System metrics: CPU, RAM, swap usage, disk I/O, disk space, load average.
• PostgreSQL metrics: active connections, slow queries, replication lag (if any), table/index sizes.
• Application metrics: web response times, worker utilisation, error rates.
• Backup health: last successful backup time, size trends, restore tests.

Alerts should be tuned realistically: no one reacts to a dashboard full of noisy warnings. Start with a small set of signals (disk space, RAM, backup freshness) and expand over time.

Routine tasks that keep ERP calm

Beyond monitoring, plan these periodic tasks:

• Review PostgreSQL query plans for the slowest reports and add or adjust indexes.
• Revisit worker counts and memory settings after major module additions.
• Rotate and clean old logs so that they do not fill disk space on the VPS.
• Patch the OS and PostgreSQL with a controlled maintenance window and tested roll‑back plan.
• Perform structured backup restore drills to a staging VPS every few months.

If you want a broader perspective on how we think about hosting Odoo and ERPNext overall, including reverse proxies and SSL, you can also read our general guide VPS hosting for Odoo, ERPNext and other self‑hosted CRM/ERP apps.

Bringing It All Together for a Calm ERP Platform

Designing the right VPS hosting architecture for Odoo and ERPNext is not about chasing the biggest CPU numbers. It is about matching resources to how these ERPs actually behave: long‑lived Python workers, chatty PostgreSQL sessions, daytime spikes in reporting and a database that slowly grows for years. When CPU, RAM, PostgreSQL configuration and backups are aligned, the result is a system that simply feels calm and predictable during office hours.

As the dchost.com team, we see the same pattern in successful deployments: start with a clear sizing plan, treat PostgreSQL as a first‑class component, adopt a 3‑2‑1 backup strategy with tested restores and keep an eye on memory and autovacuum over time. From there, you can scale up to a split app/DB architecture or add replication without redesigning everything from scratch.

If you are planning a new Odoo or ERPNext rollout, or if your current VPS feels fragile, you can take this article as a checklist: CPU/RAM headroom, PostgreSQL layout, pooling, swap, backups and monitoring. And if you want help turning these ideas into a concrete plan on dchost.com VPS, dedicated servers or colocation, our team is happy to review your requirements and propose a practical, future‑proof architecture.