Sharing a Database Between App Servers¶

A multi-tier application is often deployed across several App Servers that must share one database: an ERP back-end and a technically separate website front-end, a second front, or temporary workers. Their code differs — the only thing they have in common is the data.

Database sharing lets the App Server that owns a database grant another App Server full access to it (read/write on every table, present and future), so the whole multi-tier application works against a single database.

This page is the reference for how sharing behaves — from the GUI and from MCP (agents).

Concepts¶

Term	Meaning
Owner	The App Server whose role owns the database (the database appears in its Owned Databases list).
Grantee	An App Server granted access to a database it does not own (the database appears in its Shared Databases list).
Own Database (`home_db_name`)	The database assigned to a server at creation. Frozen, but editable. It is where a grantee returns when it stops using a shared database.
PGDATABASE (`db_name`)	The database a server connects to by default. It can point at the server's Own Database or at a shared one.

Eligibility — databases are private by default¶

In Manganese, an App Server's database is private: CONNECT from PUBLIC is revoked, so only its owner and explicitly granted roles can reach it. A private database is shareable — its Can Be Shared flag is True. Servers created from the Odoo App Definitions are private out of the box.

A public-connect database is not shareable. It is either a Beta-phase artifact or a database created by hand (a raw createdb gets PUBLIC CONNECT by PostgreSQL default — PostgreSQL cannot prevent this at creation).

Remediation — "Update Databases List". On a server kept private (Revoke PUBLIC CONNECT enabled), the Update Databases List action automatically re-closes the server's own databases that drifted public — so a hand-created database becomes private (and shareable) on the next refresh. Contact support if a public database persists.

From the owner's database — the Share Database… button on the database (form or list) opens a wizard:

Pick one or more grantee App Servers. They must be on the same PostgreSQL cluster (and, for Manganese users, within your own scope).
Set PGDATABASE for grantees (on by default): also point each grantee's PGDATABASE at this database. See Taking effect below.
Confirm.

Grantees receive FULL access: CONNECT, schema USAGE, and all privileges on every table and sequence — including tables created later by the owner (so Odoo/ERP migrations that add tables stay accessible). The list of grantees is the database's guest list.

A regular Manganese user can share only databases they own; a Manganese admin can share any database of their company.

Using a shared database, and your Own Database¶

A grantee's PGDATABASE can point at a shared database (then Using a Shared Database is true) or at its Own Database (home_db_name).

The Own Database field is set when the server is created and is kept unchanged even after PGDATABASE is repointed at a shared database — it is the anchor to come back to. It is editable if you ever need to correct it.

Front side — "Use My Own Database". A grantee repoints its PGDATABASE back to its Own Database. This is a return to your own data; it does not give up the granted access (the owner still lists you as a guest).

Owner side — "Eject". From the database's guest list, the owner revokes a grantee's access. The grantee's PGDATABASE is reset to its Own Database. Because the owner never restarts someone else's server, the grantee keeps running against the now-revoked database until its next reboot — at which point it comes back up on its Own Database.

Taking effect: next reboot¶

Repointing PGDATABASE (sharing with Set PGDATABASE, restoring, or being ejected) rewrites /etc/muppy.env on the target server without restarting it. A running process keeps its current connection until the server reboots; the new PGDATABASE applies on next start. No action ever restarts a third-party server.

Granting and revoking the access itself (the SQL privileges) is immediate; only the PGDATABASE default follows the reboot rule above.

From MCP (agents)¶

On the manganese domain:

Method	On	What it does
`mgx_share_database(grantee_server_ids, set_as_pgdatabase=True)`	`mpy.pg_database`	Share this database (full access) with the given grantee App Servers.
`mgx_unshare_database(grantee_server_ids)`	`mpy.pg_database`	Revoke (eject) the given grantees.
`mgx_restore_home_database()`	`mpy.dev_server`	Repoint this server's `PGDATABASE` back to its Own Database.

grantee_server_ids must be a list of integer App Server IDs — not names. Resolve names by searching mpy.dev_server first, then pass the ids.
Check can_be_shared before sharing; if False, the database is still public — tell the user to contact support (see Eligibility).
Read fields to inspect state: can_be_shared, shared_with_server_ids (guest list), is_using_shared_db, granted_shared_database_ids, home_db_name.

Key rules¶

In Manganese, databases are private (closed to PUBLIC); a public database is not shareable and is re-closed by Update Databases List (or contact support).
Access granted is FULL and covers future tables.
A server's Own Database is the return anchor; it is never overwritten by sharing.
Repointing PGDATABASE is effective at next reboot; no third-party server is ever restarted.
Regular users share only their own databases; admins, their company's.