{"id":5001,"date":"2026-02-11T22:42:48","date_gmt":"2026-02-11T19:42:48","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/vps-hosting-architecture-for-odoo-and-erpnext-cpu-ram-postgresql-and-backups\/"},"modified":"2026-02-11T22:42:48","modified_gmt":"2026-02-11T19:42:48","slug":"vps-hosting-architecture-for-odoo-and-erpnext-cpu-ram-postgresql-and-backups","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/vps-hosting-architecture-for-odoo-and-erpnext-cpu-ram-postgresql-and-backups\/","title":{"rendered":"VPS Hosting Architecture for Odoo and ERPNext: CPU, RAM, PostgreSQL and Backups"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_VPS_Architecture_Matters_So_Much_for_Odoo_and_ERPNext\"><span class=\"toc_number toc_depth_1\">1<\/span> Why VPS Architecture Matters So Much for Odoo and ERPNext<\/a><\/li><li><a href=\"#Mapping_OdooERPNext_Workloads_to_CPU_and_RAM_on_a_VPS\"><span class=\"toc_number toc_depth_1\">2<\/span> Mapping Odoo\/ERPNext Workloads to CPU and RAM on a VPS<\/a><ul><li><a href=\"#The_main_resource_consumers_in_Odoo_and_ERPNext\"><span class=\"toc_number toc_depth_2\">2.1<\/span> The main resource consumers in Odoo and ERPNext<\/a><\/li><li><a href=\"#Starter_growing_and_large_instances_realistic_sizing\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Starter, growing and large instances: realistic sizing<\/a><\/li><li><a href=\"#Practical_CPU_and_RAM_rules_of_thumb\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Practical CPU and RAM rules of thumb<\/a><\/li><\/ul><\/li><li><a href=\"#PostgreSQL_Architecture_for_Odoo_and_ERPNext\"><span class=\"toc_number toc_depth_1\">3<\/span> PostgreSQL Architecture for Odoo and ERPNext<\/a><ul><li><a href=\"#One_VPS_or_separate_database_VPS\"><span class=\"toc_number toc_depth_2\">3.1<\/span> One VPS or separate database VPS?<\/a><\/li><li><a href=\"#Key_PostgreSQL_settings_for_ERP_workloads\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Key PostgreSQL settings for ERP workloads<\/a><\/li><li><a href=\"#Connection_pooling_with_PgBouncer\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Connection pooling with PgBouncer<\/a><\/li><li><a href=\"#Autovacuum_and_table_bloat\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Autovacuum and table bloat<\/a><\/li><\/ul><\/li><li><a href=\"#Memory_Swap_and_Stability_for_LongLived_ERP_Sessions\"><span class=\"toc_number toc_depth_1\">4<\/span> Memory, Swap and Stability for Long\u2011Lived ERP Sessions<\/a><ul><li><a href=\"#Designing_RAM_and_swap_behaviour\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Designing RAM and swap behaviour<\/a><\/li><li><a href=\"#Common_ERP_memory_antipatterns\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Common ERP memory anti\u2011patterns<\/a><\/li><\/ul><\/li><li><a href=\"#Backup_Strategy_for_OdooERPNext_Databases_and_Files\"><span class=\"toc_number toc_depth_1\">5<\/span> Backup Strategy for Odoo\/ERPNext Databases and Files<\/a><ul><li><a href=\"#Start_from_RPO_and_RTO_not_from_tools\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Start from RPO and RTO, not from tools<\/a><\/li><li><a href=\"#What_to_back_up_for_Odoo_and_ERPNext\"><span class=\"toc_number toc_depth_2\">5.2<\/span> What to back up for Odoo and ERPNext<\/a><\/li><li><a href=\"#Logical_vs_physical_backups_and_pointintime_recovery\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Logical vs physical backups and point\u2011in\u2011time recovery<\/a><\/li><li><a href=\"#321_rule_offsite_copies_and_ransomware_resistance\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 3\u20112\u20111 rule, off\u2011site copies and ransomware resistance<\/a><\/li><li><a href=\"#Backup_encryption_keys_and_restore_drills\"><span class=\"toc_number toc_depth_2\">5.5<\/span> Backup encryption, keys and restore drills<\/a><\/li><\/ul><\/li><li><a href=\"#Example_VPS_Architectures_for_Odoo_and_ERPNext_on_dchostcom\"><span class=\"toc_number toc_depth_1\">6<\/span> Example VPS Architectures for Odoo and ERPNext on dchost.com<\/a><ul><li><a href=\"#1_Allinone_VPS_for_small_teams\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. All\u2011in\u2011one VPS for small teams<\/a><\/li><li><a href=\"#2_Split_app_and_database_across_two_VPS\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Split app and database across two VPS<\/a><\/li><li><a href=\"#3_Highavailability_direction_with_replication\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. High\u2011availability direction with replication<\/a><\/li><\/ul><\/li><li><a href=\"#Monitoring_Maintenance_and_Growth_Planning\"><span class=\"toc_number toc_depth_1\">7<\/span> Monitoring, Maintenance and Growth Planning<\/a><ul><li><a href=\"#What_to_monitor\"><span class=\"toc_number toc_depth_2\">7.1<\/span> What to monitor<\/a><\/li><li><a href=\"#Routine_tasks_that_keep_ERP_calm\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Routine tasks that keep ERP calm<\/a><\/li><\/ul><\/li><li><a href=\"#Bringing_It_All_Together_for_a_Calm_ERP_Platform\"><span class=\"toc_number toc_depth_1\">8<\/span> Bringing It All Together for a Calm ERP Platform<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_VPS_Architecture_Matters_So_Much_for_Odoo_and_ERPNext\">Why <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> Architecture Matters So Much for Odoo and ERPNext<\/span><\/h2>\n<p>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\u2011lived 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.<\/p>\n<p>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\u2011world 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.<\/p>\n<p>If you are already familiar with worker counts and reverse proxy settings, you can also read our more operational guide, <a href='https:\/\/www.dchost.com\/blog\/en\/odoo-ve-erpnext-icin-vps-hosting-rehberi-cpu-ram-worker-ve-reverse-proxy-ayarlari\/'>VPS hosting settings for Odoo and ERPNext (CPU, RAM, workers and reverse proxy)<\/a>. Here we will stay one level higher: overall VPS sizing, PostgreSQL architecture and backup strategy.<\/p>\n<h2><span id=\"Mapping_OdooERPNext_Workloads_to_CPU_and_RAM_on_a_VPS\">Mapping Odoo\/ERPNext Workloads to CPU and RAM on a VPS<\/span><\/h2>\n<p>Both Odoo and ERPNext are multi\u2011module 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.<\/p>\n<h3><span id=\"The_main_resource_consumers_in_Odoo_and_ERPNext\">The main resource consumers in Odoo and ERPNext<\/span><\/h3>\n<p>On a typical production instance you will see four main resource types:<\/p>\n<ul>\n<li><strong>Web workers<\/strong>: Gunicorn or similar workers that handle HTTP requests. Each worker consumes RAM and some CPU.<\/li>\n<li><strong>Long\u2011polling \/ real\u2011time workers<\/strong>: Used for notifications, chat and live updates. They keep connections open and use RAM steadily.<\/li>\n<li><strong>Background jobs<\/strong>: Scheduled tasks (cron jobs), email sending, report generation, integrations with other systems.<\/li>\n<li><strong>PostgreSQL queries<\/strong>: Each connected session consumes memory and CPU for query execution, especially when reports or large exports run.<\/li>\n<\/ul>\n<p>This means you rarely hit a pure CPU bottleneck first. More often, deployments start to struggle because of <strong>RAM pressure<\/strong> (swapping, OOM killer) or <strong>database contention<\/strong> (slow queries, locks) before CPU reaches 100%.<\/p>\n<h3><span id=\"Starter_growing_and_large_instances_realistic_sizing\">Starter, growing and large instances: realistic sizing<\/span><\/h3>\n<p>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\u2011backed VPS plans at dchost.com):<\/p>\n<ul>\n<li><strong>Small team (up to ~15 active users)<\/strong><br \/>2 vCPU, 4\u20136 GB RAM, fast NVMe disk, PostgreSQL on the same VPS. 2\u20134 web workers, minimal background jobs. Suitable for early deployments or pilot projects.<\/li>\n<li><strong>Growing business (15\u201360 active users)<\/strong><br \/>4 vCPU, 8\u201312 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\u20138 web workers, dedicated background worker(s).<\/li>\n<li><strong>Larger deployment (60\u2013200 active users or heavy reporting)<\/strong><br \/>8+ vCPU, 16\u201332 GB RAM across <strong>two VPS servers<\/strong>: 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.<\/li>\n<\/ul>\n<p>For very small installations, it is tempting to run with 2 GB RAM. Our experience says that is only comfortable for <strong>test\/staging<\/strong>, 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.<\/p>\n<h3><span id=\"Practical_CPU_and_RAM_rules_of_thumb\">Practical CPU and RAM rules of thumb<\/span><\/h3>\n<p>When we size VPS plans for Odoo and ERPNext at dchost.com, we use a few simple rules:<\/p>\n<ul>\n<li><strong>1\u20131.5 GB RAM per Python worker process<\/strong> (including web and long\u2011polling). This is conservative but safe for real\u2011world modules and customisations.<\/li>\n<li><strong>Leave at least 2 GB RAM for PostgreSQL and OS<\/strong> on any single\u2011VPS setup. If you cannot, reduce worker counts until you can.<\/li>\n<li><strong>vCPUs \u2248 number of simultaneous workers actually doing work<\/strong>. If you have 4 workers but only 2 vCPUs, under high load they will fight for CPU time. Some over\u2011commit is fine, but not 4\u20135x.<\/li>\n<li><strong>Plan headroom<\/strong>: keep ~30% CPU and RAM free during normal office hours. ERP load is spiky (batch imports, reporting, end\u2011of\u2011month accounting).<\/li>\n<\/ul>\n<p>For more general VPS sizing logic, you may also like our article <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-blog-woocommerce-ve-saas-icin-kac-cpu-ne-kadar-ram\/'>how many vCPUs and how much RAM do you really need<\/a>. The mindset there is the same: avoid overpaying for unused cores, but do not run at 95% utilisation all day either.<\/p>\n<h2><span id=\"PostgreSQL_Architecture_for_Odoo_and_ERPNext\">PostgreSQL Architecture for Odoo and ERPNext<\/span><\/h2>\n<p>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\u2011class citizen: right placement, right resources and right configuration.<\/p>\n<h3><span id=\"One_VPS_or_separate_database_VPS\">One VPS or separate database VPS?<\/span><\/h3>\n<p>There are three common patterns we see in real deployments:<\/p>\n<ul>\n<li><strong>Single VPS: app + PostgreSQL + reverse proxy<\/strong><br \/>Best for small teams and early phases. Simpler to manage, easier backups, fewer moving parts. Ensure enough RAM and disk IOPS.<\/li>\n<li><strong>Two VPS: app server and separate PostgreSQL server<\/strong><br \/>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.<\/li>\n<li><strong>PostgreSQL on a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation box<\/strong><br \/>For very heavy instances (large manufacturing, multi\u2011company setups) a dedicated PostgreSQL host with lots of RAM and fast NVMe can be more cost\u2011effective than many small VPS nodes. dchost.com also offers dedicated servers and colocation for these cases.<\/li>\n<\/ul>\n<p>Our rule of thumb: up to roughly 30\u201340 active users and modest reporting, a well\u2011tuned 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.<\/p>\n<h3><span id=\"Key_PostgreSQL_settings_for_ERP_workloads\">Key PostgreSQL settings for ERP workloads<\/span><\/h3>\n<p>We will not list every possible parameter, but a few have outsized impact for Odoo and ERPNext:<\/p>\n<ul>\n<li><strong>shared_buffers<\/strong>: Often set to 20\u201325% of system RAM (on the DB server). For example, 2\u20134 GB on a VPS with 16 GB RAM. Too low and PostgreSQL hits disk more often; too high and you starve the OS cache.<\/li>\n<li><strong>effective_cache_size<\/strong>: Roughly 50\u201375% of RAM. This tells the planner how much data is likely cached (PostgreSQL <em>and<\/em> OS combined) and influences index vs sequential scan decisions.<\/li>\n<li><strong>work_mem<\/strong>: Memory per sort\/aggregate operation. For ERP workloads, start low (e.g. 16\u201332 MB) and increase carefully for reporting\u2011heavy deployments. Remember this is <em>per operation<\/em>, not global.<\/li>\n<li><strong>max_connections<\/strong>: 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.<\/li>\n<li><strong>WAL settings<\/strong>: Parameters like <code>wal_level<\/code>, <code>checkpoint_timeout<\/code> and <code>max_wal_size<\/code> impact write performance and backup options. For Odoo\/ERPNext, <code>wal_level=replica<\/code> is a sensible default when you plan continuous archiving or replication.<\/li>\n<\/ul>\n<p>We wrote a full PostgreSQL performance playbook for VPS environments, including these settings, in our article <a href='https:\/\/www.dchost.com\/blog\/en\/vpste-postgresqli-ucurmak-shared_buffers-work_mem-wal-ve-pgbounceri-ne-zaman-nasil-ayarlariz\/'>the friendly VPS playbook for PostgreSQL performance<\/a>. It is not Odoo\u2011specific, but the same tuning principles apply.<\/p>\n<h3><span id=\"Connection_pooling_with_PgBouncer\">Connection pooling with PgBouncer<\/span><\/h3>\n<p>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\u2011switch overhead.<\/p>\n<p>Running <strong>PgBouncer<\/strong> in front of PostgreSQL (often on the same VPS as the DB) solves two issues:<\/p>\n<ul>\n<li>It <strong>limits the number of actual PostgreSQL backends<\/strong> while allowing many logical app connections.<\/li>\n<li>It <strong>reuses established connections<\/strong>, reducing the cost of creating and tearing down DB sessions.<\/li>\n<\/ul>\n<p>For Odoo\/ERPNext, we typically use <code>pool_mode=session<\/code> or <code>transaction<\/code> 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 <code>work_mem<\/code> and <code>max_connections<\/code>, PgBouncer often produces a more stable experience than simply adding more RAM.<\/p>\n<h3><span id=\"Autovacuum_and_table_bloat\">Autovacuum and table bloat<\/span><\/h3>\n<p>ERP systems generate a constant stream of small writes: new records, updates, deletes, log entries. PostgreSQL\u2019s <strong>autovacuum<\/strong> is what keeps dead tuples under control and indexes from growing endlessly. Misconfigured autovacuum eventually leads to performance degradation.<\/p>\n<p>On VPS deployments, we recommend:<\/p>\n<ul>\n<li>Leaving autovacuum ON, but tuning thresholds and cost limits so it can keep up during office hours without overloading the server.<\/li>\n<li>Scheduling occasional <code>VACUUM (FULL)<\/code> or <code>pg_repack<\/code> for the largest, most updated tables during maintenance windows.<\/li>\n<li>Monitoring table and index sizes over time, so you can catch bloat before it becomes a fire.<\/li>\n<\/ul>\n<p>We explain this topic in detail, with concrete parameter examples, in <a href='https:\/\/www.dchost.com\/blog\/en\/postgresql-autovacuum-tuning-ve-bloatla-barismak-vpste-pratik-ayarlar-ve-pg_repack-ile-neredeyse-sifir-kesinti\/'>our guide to PostgreSQL autovacuum tuning and bloat control on a VPS<\/a>.<\/p>\n<h2><span id=\"Memory_Swap_and_Stability_for_LongLived_ERP_Sessions\">Memory, Swap and Stability for Long\u2011Lived ERP Sessions<\/span><\/h2>\n<p>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 <strong>OOM killer<\/strong>, which might terminate PostgreSQL or app workers.<\/p>\n<h3><span id=\"Designing_RAM_and_swap_behaviour\">Designing RAM and swap behaviour<\/span><\/h3>\n<p>A few practical guidelines we apply on VPS deployments at dchost.com:<\/p>\n<ul>\n<li><strong>Always enable swap<\/strong>, but do not rely on it for normal operation. Swap is a safety net, not extra RAM.<\/li>\n<li>On small VPS (4\u20138 GB RAM), a swap size of 1\u20132x RAM is usually reasonable. On larger instances, you can keep swap smaller (e.g. 16 GB) as a buffer.<\/li>\n<li><strong>Tune PostgreSQL and worker counts<\/strong> so that under normal business load, swap usage stays near zero. Growing swap usage during the day is a smell.<\/li>\n<li>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.<\/li>\n<\/ul>\n<p>We have a dedicated article, <a href='https:\/\/www.dchost.com\/blog\/en\/vpste-ram-swap-ve-oom-killer-yonetimi\/'>managing RAM, swap and the OOM killer on VPS servers<\/a>, where we go deeper into <code>vm.swappiness<\/code>, swap file vs swap partition and monitoring patterns. The same principles keep Odoo\/ERPNext stable during peak hours.<\/p>\n<h3><span id=\"Common_ERP_memory_antipatterns\">Common ERP memory anti\u2011patterns<\/span><\/h3>\n<p>When we perform architecture reviews, we often see the same recurring issues:<\/p>\n<ul>\n<li><strong>Too many workers on too little RAM<\/strong>: People copy\u2011paste 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.<\/li>\n<li><strong>PostgreSQL sized as if it owned the whole machine<\/strong>: <code>shared_buffers<\/code> set to several GB on a small VPS where Odoo, Nginx and other services also live.<\/li>\n<li><strong>No resource isolation<\/strong>: Extra services (mail server, monitoring agents, other apps) installed on the same VPS eating RAM behind the scenes.<\/li>\n<\/ul>\n<p>The cure is simple: measure real usage with tools like <code>htop<\/code>, 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.<\/p>\n<h2><span id=\"Backup_Strategy_for_OdooERPNext_Databases_and_Files\">Backup Strategy for Odoo\/ERPNext Databases and Files<\/span><\/h2>\n<p>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 <strong>tested<\/strong> backup and restore strategy, not just a cron job running blindly.<\/p>\n<h3><span id=\"Start_from_RPO_and_RTO_not_from_tools\">Start from RPO and RTO, not from tools<\/span><\/h3>\n<p>Before choosing tools, define two key numbers with your business stakeholders:<\/p>\n<ul>\n<li><strong>RPO (Recovery Point Objective)<\/strong>: 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?<\/li>\n<li><strong>RTO (Recovery Time Objective)<\/strong>: How long can the system be down while you restore? 1 hour, 4 hours, a full day?<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/'>how to design a backup strategy<\/a>.<\/p>\n<h3><span id=\"What_to_back_up_for_Odoo_and_ERPNext\">What to back up for Odoo and ERPNext<\/span><\/h3>\n<p>At minimum, you should protect:<\/p>\n<ul>\n<li><strong>PostgreSQL database(s)<\/strong>: The main ERP database plus any extra ones you may use for staging or add\u2011on services.<\/li>\n<li><strong>Filestore \/ attachments<\/strong>: Odoo and ERPNext store file uploads on disk (e.g. <code>filestore\/<\/code> directory). Losing these breaks documents, images and some reports.<\/li>\n<li><strong>Configuration and custom code<\/strong>: Config files, installed modules, custom add\u2011ons. Often stored in Git, but your backup should cover them too.<\/li>\n<\/ul>\n<p>On a single VPS deployment, this usually means filesystem paths for PostgreSQL data directory, filestore directories and configuration under <code>\/etc\/<\/code> plus your application install path.<\/p>\n<h3><span id=\"Logical_vs_physical_backups_and_pointintime_recovery\">Logical vs physical backups and point\u2011in\u2011time recovery<\/span><\/h3>\n<p>We generally mix two types of PostgreSQL backups:<\/p>\n<ul>\n<li><strong>Logical backups (pg_dump)<\/strong><br \/>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\u2011migration snapshots.<\/li>\n<li><strong>Physical backups (pg_basebackup or backup tools like pgBackRest)<\/strong><br \/>Create a binary copy of the data directory plus <strong>WAL (Write\u2011Ahead Log)<\/strong> files for continuous archiving. Combined with WAL retention, this allows <strong>point\u2011in\u2011time recovery (PITR)<\/strong>, meaning you can restore the database to an exact moment (e.g. just before a batch import went wrong).<\/li>\n<\/ul>\n<p>For Odoo and ERPNext, our standard pattern is:<\/p>\n<ul>\n<li>Nightly logical backups for each production database.<\/li>\n<li>Continuous WAL archiving plus daily physical base backups for fast restore and PITR.<\/li>\n<li>Retention policies that keep several recent days on fast storage and older backups on cheaper object storage.<\/li>\n<\/ul>\n<p>If you want to go deeper into PostgreSQL backup tooling, we also describe a calm PITR workflow in our article about <a href='https:\/\/www.dchost.com\/blog\/en\/vps-uzerinde-postgresql-yedekleme-ve-pitr-pgbackrest-ile-wal-arsivleme-adim-adim\/'>PostgreSQL backup and PITR with pgBackRest on a VPS<\/a>.<\/p>\n<h3><span id=\"321_rule_offsite_copies_and_ransomware_resistance\">3\u20112\u20111 rule, off\u2011site copies and ransomware resistance<\/span><\/h3>\n<p>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 <strong>3\u20112\u20111 rule<\/strong>:<\/p>\n<ul>\n<li><strong>3 copies<\/strong> of your data (production + two backup copies).<\/li>\n<li><strong>2 different media<\/strong> (for example, local VPS disk + remote object storage).<\/li>\n<li><strong>1 copy off\u2011site<\/strong> (in a different data centre or region).<\/li>\n<\/ul>\n<p>Modern object storage with versioning and immutability gives you extra protection. With object lock and write\u2011once policies, even if an attacker compromises the VPS, they cannot simply delete or overwrite historical backups in your off\u2011site bucket.<\/p>\n<p>We cover this topic in detail in <a href='https:\/\/www.dchost.com\/blog\/en\/ransomwarea-dayanikli-hosting-yedekleme-stratejisi-3-2-1-kurali-immutable-backup-ve-air-gap\/'>our ransomware\u2011resistant hosting backup strategy guide<\/a>, including immutable backups and real air\u2011gap techniques.<\/p>\n<h3><span id=\"Backup_encryption_keys_and_restore_drills\">Backup encryption, keys and restore drills<\/span><\/h3>\n<p>ERP data is sensitive. Your architecture should treat backups as production data from a security perspective:<\/p>\n<ul>\n<li><strong>Encrypt backups at rest<\/strong> with strong keys. Protect both on\u2011VPS archives and off\u2011site copies.<\/li>\n<li>Store encryption keys and passwords in a separate secrets management system, not on the same VPS without protection.<\/li>\n<li><strong>Test restores regularly<\/strong>: automate a weekly or monthly restore into a staging VPS to verify that dumps are valid and procedures are documented.<\/li>\n<li>Document a simple restore runbook so that more than one person on your team can execute it under pressure.<\/li>\n<\/ul>\n<p>A backup that has never been restored is a <em>hope<\/em>, not a plan. Plan time for actual restore drills as part of your VPS architecture lifecycle.<\/p>\n<h2><span id=\"Example_VPS_Architectures_for_Odoo_and_ERPNext_on_dchostcom\">Example VPS Architectures for Odoo and ERPNext on dchost.com<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"1_Allinone_VPS_for_small_teams\">1. All\u2011in\u2011one VPS for small teams<\/span><\/h3>\n<ul>\n<li><strong>VPS<\/strong>: 4 vCPU, 8 GB RAM, fast NVMe storage.<\/li>\n<li><strong>Services<\/strong>: Nginx\/Apache reverse proxy, Odoo\/ERPNext app, PostgreSQL, PgBouncer, local backup scripts.<\/li>\n<li><strong>Use case<\/strong>: Up to ~30 concurrent users, limited heavy reporting, few external integrations.<\/li>\n<\/ul>\n<p>Backups run locally to a compressed directory, then synchronise to off\u2011site 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\u2011VPS architecture.<\/p>\n<h3><span id=\"2_Split_app_and_database_across_two_VPS\">2. Split app and database across two VPS<\/span><\/h3>\n<ul>\n<li><strong>App VPS<\/strong>: 4\u20138 vCPU, 8\u201316 GB RAM. Hosts Nginx, Odoo\/ERPNext, long\u2011polling and background workers.<\/li>\n<li><strong>DB VPS<\/strong>: 4\u20138 vCPU, 16\u201332 GB RAM. Hosts PostgreSQL, PgBouncer, backup tooling.<\/li>\n<li><strong>Use case<\/strong>: 30\u2013150 active users, multiple companies, heavier reporting, integrations with external systems.<\/li>\n<\/ul>\n<p>This layout isolates the database from application spikes. You can tune PostgreSQL more aggressively, allocate more RAM to <code>shared_buffers<\/code> 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\u2011site storage.<\/p>\n<h3><span id=\"3_Highavailability_direction_with_replication\">3. High\u2011availability direction with replication<\/span><\/h3>\n<p>When uptime requirements are strict, we add replication to the mix:<\/p>\n<ul>\n<li><strong>Primary PostgreSQL VPS<\/strong> handling writes.<\/li>\n<li><strong>Replica PostgreSQL VPS<\/strong> receiving WAL via streaming replication.<\/li>\n<li>Optionally, a <strong>read\u2011only Odoo\/ERPNext instance<\/strong> or reporting tools pointing at the replica for heavy reports.<\/li>\n<\/ul>\n<p>This does not automatically give you zero downtime (you still need failover orchestration), but it significantly reduces RTO and helps offload heavy read\u2011only traffic. We discuss replication patterns and failover concepts more generally in <a href='https:\/\/www.dchost.com\/blog\/en\/mysql-ve-postgresql-replikasyon-kurulumu-ile-vps-uzerinde-yuksek-erisilebilirlik\/'>our guide to MySQL and PostgreSQL replication on VPS for high availability<\/a>.<\/p>\n<p>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.<\/p>\n<h2><span id=\"Monitoring_Maintenance_and_Growth_Planning\">Monitoring, Maintenance and Growth Planning<\/span><\/h2>\n<p>A good VPS architecture for Odoo and ERPNext is not set\u2011and\u2011forget. 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.<\/p>\n<h3><span id=\"What_to_monitor\">What to monitor<\/span><\/h3>\n<p>At minimum, we recommend monitoring:<\/p>\n<ul>\n<li><strong>System metrics<\/strong>: CPU, RAM, swap usage, disk I\/O, disk space, load average.<\/li>\n<li><strong>PostgreSQL metrics<\/strong>: active connections, slow queries, replication lag (if any), table\/index sizes.<\/li>\n<li><strong>Application metrics<\/strong>: web response times, worker utilisation, error rates.<\/li>\n<li><strong>Backup health<\/strong>: last successful backup time, size trends, restore tests.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Routine_tasks_that_keep_ERP_calm\">Routine tasks that keep ERP calm<\/span><\/h3>\n<p>Beyond monitoring, plan these periodic tasks:<\/p>\n<ul>\n<li>Review PostgreSQL query plans for the slowest reports and add or adjust indexes.<\/li>\n<li>Revisit worker counts and memory settings after major module additions.<\/li>\n<li>Rotate and clean old logs so that they do not fill disk space on the VPS.<\/li>\n<li>Patch the OS and PostgreSQL with a controlled maintenance window and tested roll\u2011back plan.<\/li>\n<li>Perform structured backup restore drills to a staging VPS every few months.<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/odoo-erpnext-ve-diger-crm-erp-uygulamalari-icin-vps-hosting-rehberi\/'>VPS hosting for Odoo, ERPNext and other self\u2011hosted CRM\/ERP apps<\/a>.<\/p>\n<h2><span id=\"Bringing_It_All_Together_for_a_Calm_ERP_Platform\">Bringing It All Together for a Calm ERP Platform<\/span><\/h2>\n<p>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\u2011lived 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.<\/p>\n<p>As the dchost.com team, we see the same pattern in successful deployments: start with a clear sizing plan, treat PostgreSQL as a first\u2011class component, adopt a 3\u20112\u20111 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.<\/p>\n<p>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\u2011proof architecture.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 Why VPS Architecture Matters So Much for Odoo and ERPNext2 Mapping Odoo\/ERPNext Workloads to CPU and RAM on a VPS2.1 The main resource consumers in Odoo and ERPNext2.2 Starter, growing and large instances: realistic sizing2.3 Practical CPU and RAM rules of thumb3 PostgreSQL Architecture for Odoo and ERPNext3.1 One VPS or separate database VPS?3.2 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":5002,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-5001","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5001","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5001"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5001\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5002"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5001"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5001"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5001"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}