Create extra PostgreSQL users for each app or tool on Voroa

Every Voroa managed PostgreSQL database starts with one login. It is the main login, and it can do anything to that database. When you connect a reporting dashboard, a migration tool, or a teammate’s laptop, handing over that one login hands over everything.

Extra database users solve this. Each one is a separate login with its own password, scoped to that single database. You can add one for each tool, and remove it the day you stop using that tool – without changing the password your application depends on.

This is available on managed PostgreSQL. Key-Value (Redis) databases have a single login.

What an extra user can and cannot do

An extra user is a full working account inside one database, and nothing beyond it.

It can:

• Connect to that one database.
• Read and change all the data in it – select, insert, update, delete.
• Create tables, indexes, and sequences, and drop the ones it created.
• Use tables your main login creates later. You do not have to grant access again each time you add a table.

It cannot:

• Create, change, or delete other logins.
• Read the list of stored passwords.
• Install extensions.
• Delete the database.
• Reach any other database, yours or anyone else’s.

That last group is the point. A tool holding an extra user’s password cannot lock you out, cannot see your other credentials, and cannot take your database away.

Add a user

Extra users are managed through the Voroa API or the Voroa MCP server. The dashboard does not have a users screen yet.

• With the MCP server, ask your AI assistant to run create_database_user for the database, with the name you want.
• With the API, send POST /api/databases/<database-id>/users with a body of {"name": "reporting"}, using an API token from API Tokens.

Pick a name with lowercase letters, numbers, and underscores, starting with a letter – for example reporting, metabase, or app_readonly. Up to 63 characters.

Voroa creates the login and generates a password for it. You cannot choose the password yourself.

Some names are not available: postgres is your main login, and PostgreSQL reserves anything beginning with pg_. Voroa will tell you if the name you picked cannot be used.

Copy the password – it is shown only once

The moment the user is created, the response carries its password and a ready-made connection URL. This is the only time either is shown. Voroa does not store the password in any form it can read back, so there is no button anywhere that will reveal it again, and support cannot look it up for you.

Copy it straight away and put it somewhere safe, such as a password manager or your application’s environment variables.

This is the same rule your main database password follows: Voroa can replace a password, never show you one.

If you lose a password

There is no reset for an individual user, because replacing the login is the reset. Add a new user, move the tool across, and delete the old one:

1. Add a new user with a different name – reporting_v2, say.
2. Copy its password and update whatever was using the old one.
3. Confirm the tool is working on the new login.
4. Delete the old user.

Nothing is interrupted while you do this. Both logins work at the same time until you delete the old one, so there is no moment where the tool is locked out. This is also how you rotate a password on a schedule, without the downtime a straight password change would cause.

Choose which user your connection details show

One user is the default. Its name is what appears in your Connection details and in the connection URL Voroa shows you. Until you choose one, that is your main postgres login.

To change it, run set_default_database_user with the MCP server, or send POST /api/databases/<database-id>/users/<name>/default. This changes what Voroa displays – it does not change any password and does not restart your database. Anything already connected keeps working.

If you are moving your application onto its own login rather than the main one, making that login the default keeps your dashboard and your application in agreement.

Delete a user

Send DELETE /api/databases/<database-id>/users/<name>. New connections with that login are refused straight away. Connections a tool already has open stay open until they close, so restart the tool too, and make sure nothing else is still using the login.

You cannot delete the user that is currently the default. Voroa will ask you to make another user the default first. That is deliberate: deleting the default would quietly move your connection details back to the main login, which is the opposite of what you set it up for.

Logins you create yourself

If you connect to your database and run CREATE USER yourself, that login is yours, not Voroa’s. Voroa does not list it among the database’s users and cannot delete it. You manage it with SQL - for example DROP ROLE when you no longer need it.

A login like this is how you run your application as a user that does not own the database - for example so that PostgreSQL row-level security policies apply to it, because the owner login is not limited by them. It connects on the addresses Voroa shows for your database once your database has been updated to accept extra logins. It needs a normal password (PostgreSQL’s default), and names starting with voroa_ are reserved for Voroa.

Related

• How to add a managed Redis or Postgres on Voroa
• Connect to your Voroa PostgreSQL database from anywhere
• How to enable PostgreSQL extensions on Voroa
• Managed PostgreSQL on Voroa - sizes, prices and what every database includes.