Database Performance

Every Odoo service on a server shares one PostgreSQL. Out of the box that database runs with the settings its image ships, which are sized for a laptop rather than for your server — a machine with 16 GB of memory uses 128 MB of it for the database cache. calmo.cloud can size PostgreSQL for the hardware it actually runs on, and it makes sure the database and your Odoo services are not both promised the same memory.

Turning it on #

Navigate to Servers, select a server, open the Configuration page, and switch to the Postgres tab. Under the credentials you'll find a Performance section with a Let calmo.cloud tune PostgreSQL toggle.

You don't have to fill anything in. Every field is empty and shows the value calmo.cloud worked out for your server as a placeholder — that is what will be applied.

Where the numbers come from #

calmo.cloud sizes the database from the hardware your monitoring agent reports, so a server needs Telegraf monitoring enabled before a recommendation appears.

The memory of a server is divided three ways:

The Resource Budget block at the top of the Performance section shows that split for your server, with one slice per Odoo service. It also appears on the server's Metrics page and on the Performance section of each Odoo service.

The bar shows what may be taken, not what is being used: each service is counted at the memory limit it is configured with, and PostgreSQL at what its settings reserve. A service that is configured for 2 GB counts as 2 GB whether it is busy or idle, which is what makes the total a promise you can plan against. For what the machine is actually doing right now, open the server metrics.

If you share a service with another team, they see the same split for the machine their service runs on — they need it to size their own service sensibly — but never the names of anyone else's services. Those appear to them as "Another team".

PostgreSQL only gets a large cache of its own when it could actually hold the data. If the databases on a server are bigger than the memory that is spare, calmo.cloud leaves that setting where the database image has it and lets the operating system do the caching, because it does it better: measured on an 8 GB server with 35 GB of data, giving PostgreSQL a 2 GB cache cost 14% of the throughput, since every megabyte it took was one the operating system could no longer cache the same tables with. On a server whose data fits, it takes a quarter of what is spare.

Because the values are derived rather than stored, a server that is given more memory re-sizes itself: the recommendation follows the hardware, and the next time you apply, PostgreSQL grows with the machine.

Setting a value yourself #

Any of the eight fields can be filled in with your own value, for example 4GB for the shared buffers. Memory values need a unit — 512MB, 4GB — because a bare number means disk blocks to PostgreSQL.

On a server without monitoring there is nothing to size against, so calmo.cloud checks only that a value is in range — not that it fits the machine. Turn monitoring on and it also refuses shared buffers larger than 40% of the memory the server reports, which is roughly where PostgreSQL stops being able to start at all.

Clearing a field again is how you go back to the derived value. Empty means "keep deriving this", not "no value", so you never have to guess what calmo.cloud would have chosen. Reset to recommended clears all of them at once.

Settings calmo.cloud manages beyond those eight — autovacuum, checkpoints, the write-ahead log, the query planner and slow-query logging — are listed read-only under Also applied. Odoo's busiest tables need autovacuum to run considerably more often than PostgreSQL does by default, which is most of what is there. Some of the eight are computed from each other, so raising one lowers another: take more memory for the cache and each sort gets less, because both come out of the same share of the machine.

Applying, and the one restart #

Saving the section writes the settings into the running database straight away. Nothing is interrupted: PostgreSQL re-reads its configuration without dropping a single connection.

Four settings are different — the shared buffers, the connection limit, the worker processes and the autovacuum workers can only be picked up when PostgreSQL starts again. They are stored immediately and a callout appears at the top of the tab naming exactly which ones are waiting. That list comes from PostgreSQL itself, not from a list inside calmo.cloud, so it tells you the truth and disappears on its own once the restart has happened.

Nothing restarts until you press Restart PostgreSQL and confirm.

calmo.cloud also tells you when the settings PostgreSQL is running with are no longer the ones it should have — because the server was resized, or because a service was added, changed or removed. A callout appears with an Apply now button. It never applies that by itself: a database every service on the server shares is not something to reconfigure behind your back.

Database connections #

An Odoo process opens several database connections, and PostgreSQL accepts a fixed number in total. Getting that wrong is a common way to make a busy system fail in a way that looks random: services start refusing requests once the limit is reached.

calmo.cloud sizes the connection limit for the Odoo processes on the server and keeps 15 connections free for backups, monitoring and an administrator. The Database connections table shows one row per service — processes × connections per process — and says whether what your services promise fits.

The other half of that arithmetic lives on each Odoo service: the Database connections field in its own Performance section is a slice of the server's limit. The slice is worked out from the limit PostgreSQL will have once that service exists, so a second service is never handed a share that stops fitting the moment you save it — until you apply the database settings, the budget block keeps telling you the server is oversubscribed, because it is. When you click Use recommended values on a service, the value you get is that slice, and the recommendation for its memory limits is what is left after PostgreSQL's reservation and after the other services on the same server.

If you add a service and more connections end up promised than PostgreSQL allows, the budget block says so, and applying the database settings again raises the limit.

Settings calmo.cloud leaves alone #

calmo.cloud only ever writes and clears the settings it manages. Anything else you set on the database yourself stays untouched.

A few are deliberately never managed: the preloaded libraries and huge pages (a wrong value there can stop the database from starting at all), the time zone and collation (Odoo assumes UTC, and the collation is fixed when the data directory is first created), and the listening address and port (they are part of how the platform reaches the database).

What survives what #

The settings are stored inside the database's data directory, so they survive the container being recreated, a server reboot and a redeploy. They do not survive the data directory itself being rebuilt — after that, calmo.cloud applies them again by itself on the next database deployment.