Database Users & Logical Databases

TL;DR — Use the Users and Databases tabs on your cluster to add dedicated user accounts and logical databases. Never use the default admin user from your application — create a least-privilege user for each app.

Every managed cluster comes with one admin user (doadmin) and one default database (defaultdb for SQL engines, admin for MongoDB). Most teams add more — one user per application, one database per environment or per service.

Users

The Users tab on your cluster lists every database user. Each row shows the username and role (primary admin, normal, or replication).

Why You Should Add Users

• Principle of least privilege. App A should not be able to read App B's tables.
• Credential rotation. Rotate one app's password without breaking the others.
• Audit logs become useful. Slow query logs and connection logs are tied to usernames.
• Easier offboarding. Delete a leaving team member's user without touching anything else.

Create a User

1. Open your cluster → Users
2. Click Add User
3. Enter a username (alphanumeric, hyphens allowed)
4. Click Create

The cluster generates a random password and shows it once in a banner at the top of the page with copy and show / hide controls.

⚠️ Save the password immediately. It is not retrievable after you close the banner. If you lose it, delete the user and recreate it.

Delete a User

Click the trash icon next to the user. The primary admin (doadmin) cannot be deleted.

Deleting a user invalidates its connections immediately and breaks any application using it — coordinate the change with deployment.

Engine-Specific Notes

PostgreSQL — users created in the UI are role members with LOGIN and can be granted permissions via SQL. To restrict to a specific database / schema, connect as doadmin and run e.g.:

REVOKE ALL ON DATABASE defaultdb FROM new_user;
GRANT CONNECT ON DATABASE my_app TO new_user;
GRANT USAGE ON SCHEMA public TO new_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO new_user;

MySQL — users default to % host. Restrict with GRANT ... ON my_app.* TO 'new_user'@'%'.

MongoDB — users are created with readWrite on the admin database by default. Adjust roles per database via the Mongo shell.

Valkey — Valkey 8 supports ACLs. Newly created users default to ~* +@all. Restrict commands with ACL SETUSER over the Valkey CLI.

Kafka — users map to SASL credentials. ACLs (topic-level read/write) are managed via Kafka admin tools.

OpenSearch — users are mapped to security roles via the OpenSearch Security plugin.

Logical Databases

The Databases tab lists logical databases inside the cluster. Use one database per application — or one per environment within an app — to keep data isolated.

Create a Logical Database

1. Open your cluster → Databases
2. Click Add Database
3. Enter a database name (lowercase letters, numbers, underscores)
4. Click Create

The new database appears in the list. Connect to it by changing the database segment of your connection URI:

postgresql://user:password@host:25060/my_new_database?sslmode=require

Delete a Logical Database

Click the trash icon next to the database. The default defaultdb and the internal _dodb database cannot be deleted.

Deleting a database is irreversible — all tables, indexes, and data inside it are gone. The cluster's automated backups still contain the data; you can request a restore (see Backups & Restore).

Engine Differences

• PostgreSQL / MySQL — full logical database support, multiple databases per cluster.
• MongoDB — databases are created automatically on first write. The UI lets you pre-create them so you can grant users access ahead of time.
• Valkey — supports 16 numbered databases (0–15) via SELECT n; not exposed in the UI.
• Kafka — no logical databases; data is organised by topics (managed via Kafka admin tools).
• OpenSearch — no logical databases; data is organised by indexes.

Recommended Pattern

For a typical web app:

1. One cluster per environment (or one per service in mature setups)
2. One logical database per app — e.g. myapp_production
3. One user per app — e.g. myapp_app
4. Grant only the privileges that user needs — typically SELECT/INSERT/UPDATE/DELETE on the schema, no DDL except during migrations
5. A separate myapp_migrator user with DDL rights, used only during deploys

This pattern means a compromise of the runtime credentials can't drop tables, and rotating credentials is a single password change.

Troubleshooting

Password banner disappeared and I didn't save it

Delete the user (top right of the row) and recreate it. The new password will be shown.

Can't delete a user

The primary admin (doadmin) is protected. You also can't delete a user that owns objects in PostgreSQL — reassign ownership first with REASSIGN OWNED BY old_user TO new_owner then drop.

"permission denied for table" after creating a new user

PostgreSQL users get no privileges on existing objects by default. Grant explicitly (see PG note above) or use ALTER DEFAULT PRIVILEGES so future tables inherit permissions automatically.

Related Guides

• Connect to Your Database
• Connection Pooling
• Firewall & Trusted Sources
• Backups & Restore