# Database users and roles
Database users are separate from your Atlas login. You create them under Security, Database Access, and the driver authenticates as that user.
## Role guide
- `readWrite` on a specific database: what most app services need. Reads and writes, nothing else.
- `read` on a specific database: analytics, reporting, read-only agents.
- `readWriteAnyDatabase`: services that touch many databases.
- `atlasAdmin`: migrations, index management, sharding admin, backup tooling. Powerful; do not hand it to every service.
- `backup` / `clusterMonitor`: narrow roles for backup jobs and monitoring agents.
## Rules
- One user per service, named after the service. When a key leaks or a service is retired, you revoke one user instead of rotating a shared credential.
- Start with the narrowest role that works. A `not authorized` error tells you exactly which privilege is missing; widen deliberately, not by jumping to atlasAdmin.
- Custom roles exist for fine-grained needs (a user that can read one collection and write another). Use them before inventing workarounds.
- SCRAM is the auth mechanism. Special characters in passwords must be URL-encoded in the connection string.
## Verify
After creating the user, connect with its credentials and run one representative write and one admin command you expect to fail. The failure confirms the boundary is real.