> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Database roles: owner, runtime and additional roles

> Use DBHost managed SQL roles: owner for migrations, runtime for your app, read-only for reporting, plus up to ten additional roles per database.

With **Managed SQL roles**, each database gets separate PostgreSQL logins
instead of one shared password. Choose the option when you create a database
in the dashboard (every plan), or use the
[managed-create API](/api-reference/databases/managed-create) on Pro or
Business.

## Base roles

| Role | Use it for | Privileges |
| - | - | - |
| **owner** | Migrations and schema changes | Owns the schema and objects; can run DDL and grant access |
| **runtime** | Your application | Reads and writes data; cannot run DDL |
| **read-only** | Reporting, BI and support queries | `SELECT` only |

Each role has its own generated username and password. The database name is
not a username. Reveal or rotate one credential at a time on the database
detail page; rotating one role does not change the others. Rotation and
revocation close that role's open connections. See
[Managed role changes](/api-reference/databases/role-changes) for the API.

## Additional roles

You can add up to **10 additional roles** per database, for example a
separate login for a worker, an analytics tool or a contractor. Pick one
access profile when you create the role:

| Profile | What DBHost grants |
| - | - |
| **Read only** | `CONNECT` plus `SELECT` |
| **Read & write** | `CONNECT` plus DML: `SELECT`, `INSERT`, `UPDATE` and `DELETE` |
| **Custom** | `CONNECT` only. The role can log in immediately but sees no tables until your migrations grant access |

DBHost never gives an additional role `CREATE`, `TEMPORARY`, superuser,
`CREATEDB`, `CREATEROLE` or replication privileges. Each role has its own
connection limit, and all roles share the database's
[server connection cap](/guides/connection-limits-and-timeouts).

### Grant access to a Custom role

Run grants as the **owner** role, ideally in a migration so they are
versioned with your schema. Replace `reporting_role` with the generated
username shown in the dashboard:

```sql theme={null}
GRANT USAGE ON SCHEMA public TO reporting_role;
GRANT SELECT ON public.orders, public.customers TO reporting_role;

-- Tables the owner creates later get the same access automatically.
ALTER DEFAULT PRIVILEGES FOR ROLE CURRENT_USER IN SCHEMA public
  GRANT SELECT ON TABLES TO reporting_role;
```

`ALTER DEFAULT PRIVILEGES` only applies to objects created later by the role
that runs it, so run it as the owner role that runs your migrations.

## Manage additional roles

On the database page, open the **Roles** tab. Under **Extra roles** (or
**Additional database roles** on an existing single-login database), the owner
can:

* **Add** a role with a name, access profile and connection limit
* **Reveal** its password when you need to configure a client
* **Rotate** its password; open sessions are disconnected
* **Revoke** it; new logins and active sessions are denied
* **Remove** a revoked role to free its slot

These actions are available in the dashboard on every plan. The
[API](/api-reference/databases/additional-roles) and the
[CLI](/cli) (`dbhost managed custom-*` commands) require Pro or Business.

## Existing databases

A database created before managed SQL roles keeps its single login. The owner
can opt in to additional roles from the **Roles** tab. The existing login,
password and connection string stay unchanged.

Backups made before opt-in do not include the additional roles. After opt-in,
DBHost-produced backups of that database can be restored in place; see
[Restore from a DBHost backup](/guides/restore-from-backup). Cloning a
database that has additional roles is not offered and returns
`409 LEGACY_OVERLAY_REQUIRES_V4`.

## Dashboard team access is separate

SQL roles control what a PostgreSQL login can do. Dashboard
[team access](/dashboard/databases#team-access) controls what another DBHost
user can see and change in the dashboard. The two are independent.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.