App users
Logins for your applications, and what each one may do
An app user is a login HiveOps created for an application, as distinct from a PostgreSQL role that happens to exist in the database. HiveOps tracks which is which, because the distinction does not exist in PostgreSQL and guessing it from names would be guesswork.
Give each application its own. A login you can revoke, expire and restrict without disturbing anyone else is worth the minute it takes to create.
Capabilities
Permission is a set of capabilities rather than per-schema access.
| Capability | What it grants |
|---|---|
| Read | SELECT on the tables and views of the database |
| Read and write | Read, plus INSERT, UPDATE and DELETE, and the sequences behind identity columns |
| Change the schema | Creating and altering tables and their columns, and creating views, functions, procedures and schemas |
Two things about how these fit together.
Read and write contains read rather than sitting beside it, so a login that writes does not need both. Granting both says the same thing twice.
Changing the schema is orthogonal to the other two rather than a level beyond them. A migration login that may reshape the database and read nothing out of it is a real thing to want, so a user that needs both carries both.
A new app user starts on read and write alone. Reshaping the database is not something an application login gets by default.
Capabilities are group roles that the cluster granted the matching privileges to once, and a user holds a capability by being a member of that role. Changes apply as soon as they are ticked.
Passwords
A password is generated when the user is created. You do not have to write it down: the user's page can reveal it again whenever you need it, because the backend kept it. PostgreSQL only stores a hash, so this is possible only because HiveOps stored it too.
Resetting a password replaces it immediately. Anything still connecting with the old one stops working, with no grace period.
Limits and expiry
An app user can carry a connection limit and an expiry.
A connection limit caps how many connections that login may hold at once, which stops one misbehaving application from exhausting the database for everything else.
An expiry makes the login stop working at a date you choose. This is the honest way to hand out temporary access.
Deleting one
The login stops working immediately.
PostgreSQL refuses to drop a role that owns anything, so if the user owns tables, views or sequences, the console says what is in the way rather than letting the database refuse it cryptically. Reassign or drop those objects first.
Objects a deleted user owned are not deleted with it.
There is no rename
The update endpoint identifies a user by name, so the name is its identity. To change it, create a new user and delete the old one.