Enter your server and get the odoo.conf for your live system and every test copy, plus the postgresql.conf for the database they share. It runs the same arithmetic calmo.cloud applies to every server it manages.
What each part may take at most, not what it uses on a quiet afternoon. A plan is only safe if the promises add up.
15.2 GB of 16 GB promised. Everything fits.
17 Odoo processes · Odoo may open 90 of the 110 database connections PostgreSQL accepts.
One block per Odoo. Memory limits are in bytes, which is how Odoo reads them.
[options] workers = 9 max_cron_threads = 2 limit_memory_soft = 939524096 limit_memory_hard = 2147483648 limit_time_cpu = 600 limit_time_real = 1200 limit_request = 8192 db_maxconn = 6
9 workers and 2 cron threads · 896 MB soft and 2 GB hard limit per process · 6 database connections per process
[options] workers = 4 max_cron_threads = 2 limit_memory_soft = 536870912 limit_memory_hard = 2147483648 limit_time_cpu = 600 limit_time_real = 1200 limit_request = 8192 db_maxconn = 4
4 workers and 2 cron threads · 512 MB soft and 2 GB hard limit per process · 4 database connections per process
One PostgreSQL for all of them. Add the lines to postgresql.conf or set them with ALTER SYSTEM. shared_buffers, max_connections, max_worker_processes and autovacuum_max_workers only take effect after a restart.
shared_buffers = '128MB' effective_cache_size = '8192MB' work_mem = '15MB' maintenance_work_mem = '512MB' max_connections = 125 max_worker_processes = 4 max_parallel_workers = 4 max_parallel_workers_per_gather = 1 max_parallel_maintenance_workers = 2 autovacuum_max_workers = 3 autovacuum_work_mem = '128MB' autovacuum_naptime = '30s' autovacuum_vacuum_scale_factor = 0.05 autovacuum_analyze_scale_factor = 0.02 autovacuum_vacuum_cost_limit = 1000 min_wal_size = '1024MB' max_wal_size = '4096MB' checkpoint_completion_target = 0.9 random_page_cost = 1.1 jit_above_cost = 500000 effective_io_concurrency = 200 default_statistics_target = 100 log_min_duration_statement = '1000ms' log_lock_waits = 'on' log_checkpoints = 'on' log_temp_files = '10MB'
Textbook PostgreSQL tuning assumes the database has the server to itself. Odoo's deployment guide assumes the database runs somewhere else. Follow both on one machine and they hand out the same memory twice.
| For this server | Textbook + Odoo guide | This calculator |
|---|---|---|
| PostgreSQL shared_buffers | 4 GB | 128 MB |
| PostgreSQL effective_cache_size | 12 GB | 8 GB |
| PostgreSQL work_mem | 20.1 MB | 15 MB |
| PostgreSQL max_connections | 200 | 125 |
| Odoo processes, all instances | 18 | 17 |
| Connections Odoo may open | 1,152Odoo may open 1,152 database connections, but PostgreSQL only accepts 200. | 90 |
| Memory PostgreSQL and Odoo may take | 40 GBmore than the server hasOdoo's guide estimates 9.7 GB | 13.6 GB |
Textbook PostgreSQL tuning for a web application on Linux with SSDs: a quarter of the memory for shared_buffers, three quarters for effective_cache_size, 200 connections. Odoo's rule of (cores × 2) + 1 processes applied to every instance, with the limits it leaves unset at Odoo's defaults: 2 GB soft memory limit and 64 connections per process. The guide's estimate counts a fifth of the requests as heavy at 1 GB and the rest at 150 MB.
Sources: Odoo's deployment guide and OdooBench. Values are a starting point for a typical Odoo workload; watch your server after applying them.
Textbook tuning gives PostgreSQL a quarter of the memory. Next to Odoo, that memory comes out of the operating system's page cache, which was already caching the same tables. PostgreSQL only gets a large cache of its own when the databases fit into what is left over.
Odoo's rule sizes one system for the whole machine. A test copy gets a share of the server instead, so it cannot take the room your live system needs.
Every Odoo process may open 64 connections by default. The limit is split between all processes on the server, with 15 kept free for backups, monitoring and you.
Each worker gets a small steady-state share, but the hard limit leaves room for one big export or report to complete, capped at half the memory so one runaway cannot take the server down.
On calmo.cloud nobody copies these numbers by hand. The platform reads the hardware from its monitoring agent, sizes Odoo and PostgreSQL together, and tells you when a new service or a bigger server calls for new values. The rules behind this calculator were checked on real servers before they went in.
more requests per second on the same 4-core, 8 GB server: 140 untuned, 273 tuned
typical wait per click, from 55 to 28 milliseconds
the throughput on a 16-core server with 84.5 million records: 59.9 requests per second untuned, 508.2 with Odoo and the database tuned
On an 8 GB server with 35 GB of data, a 2 GB buffer pool cost 14% of the throughput against PostgreSQL's default, because it squeezed the operating system's cache.
PostgreSQL's query compiler kicked in on short queries over large Odoo tables. It now waits for queries that are actually expensive.
A hard limit of 1.25 × the soft limit killed a grouping of two million values. At 2 GB it finishes in 8.3 seconds.
4-core figures: Odoo 19 and PostgreSQL 18 with 16.9 million records, eight logged-in users sending the calls the web client sends, 60 seconds of warm-up and three 90-second runs per variant, median of the runs, no errors. The 16-core figures are published in the OdooBench README.
OdooBench is our open-source benchmark for Odoo. It logs in as a real user and replays what the web client sends when someone opens, filters or groups a list, then tells you whether a change actually moved anything. Run it before and after you apply these settings.
pip install git+https://github.com/havmedia/OdooBench odoobench run --url http://10.0.0.5:8069 --db production \ --login admin --scenario office-day --users 50 --out before.json odoobench compare before.json after.json
Yes, with no sign-up. The numbers are yours to use on any server, with or without calmo.cloud.
Because on a server that also runs Odoo, a big PostgreSQL cache takes memory from the operating system's cache, which does the same job. We measured a 14% throughput loss with a pool of the usual textbook size. PostgreSQL gets a larger cache as soon as your databases fit into the memory that is left over.
A test copy is there to try things, not to serve your whole team. It is sized for a share of the server, so the live system keeps the room it needs even with several copies running.
No. The numbers are only used to calculate this page.
You do not enter anything. The platform reads the cores and memory from the server, the database size from PostgreSQL, and recalculates when you add a service or resize the server. It never restarts the database behind your back, and if PostgreSQL refuses a value, it rolls that value back by itself.
Join the waitlist for early access and launch updates. Bring your Odoo. Keep your independence.
We use privacy-friendly analytics to see how the site is used. Nothing is stored until you have chosen.
Pick the categories you allow. You can change this at any time from the footer.