Databases

The PostgreSQL instances your apps run on: each app's own database and logins, an instance's connection and settings, deploying and deleting one, and who may do what.

Developer Plus Updated 11/03/2026

Database instances

A database instance is one PostgreSQL server that the platform runs in a container on one of your servers. It belongs to one environment of a project. A new app is created on its environment's instance, or on the one the environment's Defaults name for its Odoo version (see Environment settings), so one instance usually serves several apps.

Each app has a database of its own inside the instance, and two logins of its own on it:

A Read & Write role, which owns the app's database. The app's code runs as it, and it cannot reach any other app's database.
A Read role, which can only read the app's database. Backups use it, and so does pgAdmin from the app's screen.

The instance also has a login of its own, its superuser, which reaches every database on it. The platform uses it on the server to make, copy and drop the apps' databases; the apps connect with their own roles.

What you set on an instance applies to every app on it: its PostgreSQL version, its settings, and a restart. A project can have several instances, for example a second one on a newer PostgreSQL version. Maintainers move an app to another instance on the same server from the app's Database field, on its Configs tab (see Settings).

The project's databases

The project's PostgreSQL instances, one card each.

You can

Open an instance by clicking its name.
Run an instance's actions from the menu (⋮) on its card (Deploy, update and delete).
Search by name, user, host, environment or server.
Add an instance with Create (Create an instance).

Good to know

An eye marks an instance you may read but not change.
External in a card's footer marks a database you run yourself; the platform only connects to it.
Only approved projects show their databases: a project waiting for approval cannot create or deploy one (Create a project).

Create an instance

Create opens a dialog in two parts, Instance and Where It Runs.

Field	What it is
Database Name	The instance's name. It names its container, so it must be unique on its server and is fixed once deployed.
Username, Password	The instance's own login, its superuser. Type a password or let the wand suggest a strong one. Both are fixed once deployed, and the password is not shown again.
Port	The port the instance takes on its server. Each instance on a server needs its own: when the one you enter is taken, the platform picks a free one.
External Database	On for a database you run yourself: the platform only connects to it. You then give its External Host and Maintenance DB.
Deployment Server, Docker Image	The server the platform runs it on, and its PostgreSQL image. Left empty, the image is the platform's default one.
Environment	The environment that will use it. Required.

Create saves the instance as Draft. Nothing runs on the server until you click Deploy. Creating one takes the Developer Plus role.

An instance's screen

One PostgreSQL instance: where it runs, how the apps reach it, how it is set up, and what happened to it.

You can

Change its settings on the Info, Connection and Configs tabs.
Press Save on the title row to store your changes, or Reset to drop the unsaved ones.
Deploy, update or delete it from the title row (Deploy, update and delete).
Follow its runs under Operations (Following a run), and read its changes in Database History.

Good to know

Save changes the record only: the image and the PostgreSQL settings reach the server with the next Update.
What you set on an instance applies to every app on it.
An Update restarts PostgreSQL: every app on the instance is cut off from its database until it is back.

General

Which server and PostgreSQL image the instance runs on, and the project it serves.

You can

Pick another Docker Image and press Save: the image is the only thing you can change here.
Pick a pgvector image when an app needs vector search for AI features.
Read Deployed Date for the day of its last Deploy or Update.

Good to know

The image sets the PostgreSQL version. The next Update pulls a new one and restarts PostgreSQL.
Once deployed, another tag of its PostgreSQL major version is accepted; another version is refused.
To move to a newer PostgreSQL, create an instance on it and move the apps there.
The name and the server never change: the apps connect to the container the name gives, and the data lives on that server.
Changing the image takes the Developer Plus role.

Connection

How the apps reach this instance, and whether its superuser may sign in from the network.

You can

Change the Port it takes on its server, one no other instance there uses; the next Update brings it there.
Change the Maintenance DB, used for administrative operations (postgres unless you change it).
For an external database, set the External Host, port, username and maintenance database of the server you run.
Look at an app's data with pgAdmin from the app's Access menu: it connects as the app's Read role.

Good to know

External Database can be turned on only before the first deploy; afterwards, delete the instance and add the external database as a new one.
With Admin Login From the network, anyone holding the superuser's password can connect from another container or through a tunnel.
Our team locks it to On the server only once every app on the instance runs on its own roles; the apps are not affected.
Once it is locked, only root on the server reaches the superuser: pgAdmin and tunnels can no longer sign in as it.
Changes here take the Developer Plus role.

Roles

Each app's own logins on this instance: one the app runs as, one that only reads.

You can

See which app each role belongs to; the list shows the apps you can see.
Reveal an active Read role's password with Reveal password, after you enter your own.
Open an app's data in pgAdmin from the app's Access menu: it connects as the Read role, with no password to type.

Good to know

The Read role reads every table, password hashes and API keys included: share its password as you would the data.
The Read role holds at most five connections at once, so a reporting tool cannot take the app's connections.
The Read & Write role's password is never shown: only the app uses it.
An app gets its roles when it is first deployed. One deployed before per-app roles connects as the instance's login until moved onto its own.
Revealing a password is for the namespace's Maintainers and Admins.

Storage

Where on its server the instance keeps its data, every app's database included.

You can

Read the Storage Path, the folder on the server that holds the instance's data.
Back up an app from that app's own Backups: backups are taken per app (Backups & restore).

Good to know

The path is set when the instance is created and cannot be changed.
The data stays in that folder through every Update and restart.
Deleting the instance from its server removes the folder and every database in it, and cannot be undone (Deploy, update and delete).

PostgreSQL Settings

The PostgreSQL settings the instance runs with, shared by every app's database on it.

You can

Change a value in its field; sizes and times take a unit, as 256MB or 5min.
Add a tuning setting not set yet with Add a setting…; it starts at its default.
Remove one with the cross beside it: PostgreSQL then uses its own default.
Put back what a new instance starts with, such as max_connections 500, with Reset to defaults.

Good to know

Each value is checked at Save: one PostgreSQL would refuse, or outside a safe range, is refused with the values it takes.
The next Update writes the settings and restarts PostgreSQL: every app on the instance is cut off from its database until it is back.
Only tuning settings can be added; lines marked Set by the platform are read-only.
autovacuum stays on, and statement_timeout is at least one minute, or 0 for none.
Changing settings takes the Developer Plus role.

Deploy, update and delete

An instance's actions are on the title row of its screen, and in the menu (⋮) on its card in the list. You only see the ones you may run, and each asks you to confirm.

Action	What it does	When it is offered
Deploy	Sets the instance up on its server and starts PostgreSQL. The first deploy creates its data; later ones keep it.	Draft, Deployed or Error.
Update	Runs the same steps on the running instance: writes the current PostgreSQL settings, pulls the image and restarts PostgreSQL. The data stays.	Deployed or Error.
Retry	Runs the failed run again.	Error.
Delete (More, Danger Zone)	Removes the instance; see below.	While no app uses it.

While Deploy or Update restarts PostgreSQL, every app on the instance is cut off from its database. Follow the run under Operations.

Delete acts on what is left:

On a deployed instance, it stops PostgreSQL and removes the instance from its server, with its data folder and every database in it. You confirm twice, the second time by typing DESTROY. Its state then reads Deleted.
On an instance never deployed, or one whose delete has run, it removes the record. You confirm by typing DELETE.

While any app uses the instance or is moving to it, Delete is disabled and says how many apps hold it: delete them, or move them to another database, first. A delete cannot be undone.

Who may do what

What you may do with a database depends on your role in the namespace. Unlike an app's, it is the same in every environment. A role may also do everything the rows above it allow.

Action	Role
See the Databases list, an instance's tabs and its roles	Viewer
Create an instance; change its image, connection or PostgreSQL settings; Deploy, Update, Retry	Developer Plus
Delete an instance or its record	Maintainer
Reveal an app's Read role password; open pgAdmin from the app's Access menu	Maintainer
Move an app to another instance	Maintainer

Locking the admin login and changing a role's password are done by our team. See Permissions & access for every role.

Was this page helpful?

Your answer helps us prioritize documentation improvements.