Managing databases

Every Odoo database of every instance lives in the one shared ohm-postgres container. An instance owns its databases; one of them is the active database that the instance serves.

In the console, a database is reached through its instance. PostgreSQL is the other view of the same thing: the server's PostgreSQL profiles and every database on it, whoever owns it.

Creating and initialising

Remote or localagainst pelmo

$ ohm instance database create --instance fanes

Remote or localagainst pelmo

$ ohm instance database init --instance fanes --country BE

create makes an empty PostgreSQL database. init runs Odoo's own initialisation into it, which is what turns it into an Odoo database. -c, --country is required: it is the two-letter ISO code Odoo initialises the localisation with. Add --activate to make the new database the one the instance serves in the same step.

Databases per instance	Unregistered	Community	Developer	Professional	Provider
Limit	1	1	Unlimited	Unlimited	Unlimited

A new instance's first database is created with the instance: the New instance wizard's Database tab and ohm instance create both create and activate one once the instance is installed, set up for a country, with the Odoo administrator's Admin login (admin by default) and Admin password you choose there. Left empty, the password is generated.

The generated administrator password

A database whose administrator password was generated shows an Administrator password card on its page: the password can be shown once, to whoever created the database, within an hour of its creation. Show the password reveals it with a copy button; copy it then, because it is not shown again. After that, or for anyone else, reset the password on the database's Users tab. ohm instance create prints a generated password once at its end instead.

Listing

Remote or localagainst pelmo

$ ohm instance database list --instance fanes

Remote or localagainst pelmo

$ ohm instance database size --instance fanes

Every database on the server's PostgreSQL, whichever instance owns it - or none. This one runs on the host, against the engine rather than through the management API, which is what makes it useful when the management plane is the thing you are investigating:

Local only

$ sudo ohm server database list

Cloning

Remote or localagainst pelmo

$ ohm instance database clone --instance fanes

Cloning is the normal way to make a test copy of production: it copies the database within the same PostgreSQL server, which is far faster than dumping and loading.

Dumping and loading

Remote or localagainst pelmo

$ ohm instance database dump --instance fanes

Remote or localagainst pelmo

$ ohm instance database load --instance fanes

dump and load move a database as a file. That is what you want when the destination is a different server, or when the file is going somewhere Antelao does not manage.

Note that load counts as a restore for licensing purposes:

Requires the Professional edition

Load a database from a standard PostgreSQL dump in custom, tar or plain SQL format, detected automatically, and export databases as PostgreSQL dumps for use anywhere.

Available on Developer, Professional, Provider. Elsewhere the operation is refused and nothing is changed.

Renaming and removing

Removing a database cannot be undone

Removing a database drops it from PostgreSQL and deletes its filestore - its attachments - with it. Nothing keeps a copy. Take a backup of the database first, and make sure it is not the one the instance serves.

Renaming

Renaming takes the database offline while it runs: every connection to it is cut and new ones are refused until the rename is done. Its filestore is renamed with it, and when it was the instance's active database, the instance serves it under its new name afterwards.

Remote or localagainst pelmo

$ ohm instance database rename --instance fanes --database fanes --name fanes_2025

The command says the database goes offline and asks whether to go on; the answer is no unless you say yes. Over a connection, -n, --name is required.

Removing

1. Back the database up, and wait for the job to succeed:

   Remote or localagainst pelmo

   $ ohm instance database backup --instance fanes --database fanes_old

2. Check it is not the active database. The database list marks the active one. Removing the active database over a connection leaves the instance serving no database at all until you activate another, so activate the one it should serve first.

   Remote or localagainst pelmo

   $ ohm instance database list --instance fanes

3. Remove it:

   Remote or localagainst pelmo

   $ ohm instance database remove --instance fanes --database fanes_old

   The command asks you to type the database's exact name, capitals included, and does not go on until it matches; break off with Ctrl+C. It has no option to pass the name, so it needs a terminal. On the instance's Databases tab, the delete button asks the same: the database is deleted only once its name is typed.

Only a database the instance owns can be removed; one owned by another account is refused. The way back is the backup from step 1, restored as Restoring a database describes.

Activating

Remote or localagainst pelmo

$ ohm instance database activate --instance fanes

The active database is the one the instance serves. Switching it is how you promote a restored or cloned database into production.

Maintenance

Remote or localagainst pelmo

$ ohm instance database vacuum --instance fanes

Remote or localagainst pelmo

$ ohm instance database reindex --instance fanes

Both can also be scheduled. See Maintenance.

Odoo users inside a database

Antelao can manage the Odoo-side accounts in a database, separately from the management UI's own users:

Remote or localagainst pelmo

$ ohm instance database user list --instance fanes

Remote or localagainst pelmo

$ ohm instance database user password-reset --instance fanes

Remote or localagainst pelmo

$ ohm instance database user totp-disable --instance fanes

These are break-glass tools for when someone has locked themselves out of Odoo itself. They are not a substitute for managing users inside Odoo.

Sign-in protection

Odoo can put two challenges in front of its sign-in: its own reCAPTCHA module (Google reCAPTCHA), and Cloudflare Turnstile through Odoo's Turnstile module, which the portal sign-in check relies on. A database's Sign-in protection tab shows both and switches them; it is there for an Odoo database only. A role that may change the instance reads the settings from the database when it opens the tab, not before; Refresh reads them again. Every role sees what was read last.

Row	What it says
reCAPTCHA State	Whether Odoo's reCAPTCHA module is installed, whether it is switched on, and whether a public key is set. Not set counts as on, which is how Odoo reads it
reCAPTCHA Enabled	Switches reCAPTCHA on or off
Turnstile State	Active only when Odoo's Turnstile module is installed, both keys are set and the environment preset has not parked them
Keys	Whether the site key and the secret key are set
Bypass the portal Turnstile	Lets the portal sign-in skip Turnstile: the way back in when Turnstile keeps everybody out
Count failed checks as failed sign-ins	On by default: a failed check is written to the instance's Odoo log as a failed sign-in. From 0.24.0 the server's Fail2Ban jail reads the web server's log instead, where a sign-in a failed check sends back to the sign-in page counts whatever this switch says
Site key / Secret key	Sets the keys. The secret key is never shown: type a new one to replace it
Remove the keys	Removes both keys, which switches Turnstile off
Restart the instance after saving	On by default. Odoo reads these settings when it starts, so each change restarts the instance afterwards when it is running; a stopped instance stays stopped

Every change is a job, and the card reads the settings again once it has run. On a database without Odoo's Turnstile module the Turnstile controls are disabled: nothing is installed for you. A non-production environment preset switches Turnstile off by parking its keys; while they are parked, new keys are refused until the preset changes or the database options are applied again. The bypass and the failed-check setting need the portal sign-in check in the database.

From the command line, the same settings for one database:

Remote or localagainst pelmo

$ ohm instance database turnstile --instance fanes --database fanes

Without a change option it shows the settings and changes nothing. The changes:

Option	Effect
--bypass on / off	Switches the portal bypass on, or off again
--count-failures on / off	Whether a failed check counts as a failed sign-in (on is the default)
--site-key <key>	Sets the public site key
--secret-key	Prompts for the secret key with the input masked. --secret-key-file <path> and --secret-key-stdin read its first line from a file or from standard input instead. A key typed on the command line is refused, so it never lands in the shell history
--clear-keys	Removes both keys. Keys a preset has parked are left to the preset
--restart, --no-restart, --yes	Answer the restart question. Without a terminal and without one of them, the instance is not restarted and the command says so

Remote or localagainst pelmo

$ ohm instance database turnstile --instance fanes --database fanes --bypass on --restart

Remote or localagainst pelmo

$ ohm instance database recaptcha --instance fanes --database fanes --enable false --restart

Run on the server itself with --local, the Turnstile command works when the management API and the console are down: it needs only the instance's PostgreSQL, and it records what it changed - never a key - in the audit trail. See Locked out of an Odoo portal.

Other operations

Command	What it does
instance database shell	A psql session against the database
instance database cloc	Counts lines of code in the database's custom modules
instance database comment get / set	Reads and writes the database's PostgreSQL comment
instance database migrate-filestore	Moves the Odoo filestore
instance database reset-permissions	Repairs ownership and grants
instance database sysadmin create / remove	Manages the database superuser account
instance database recaptcha	Switches reCAPTCHA on or off in the database. See Sign-in protection
instance database turnstile	Shows and changes the database's Turnstile settings. See Sign-in protection

Related

• Modules
• Backup and restore