Members & roles
A namespace member is a user × namespace × role. Roles control what’s visible and what’s mutable in the console and the REST API.
Role permissions
Section titled “Role permissions”| Viewer | Editor | Admin | Owner | |
|---|---|---|---|---|
| List databases | ✓ | ✓ | ✓ | ✓ |
| Read tables | ✓ | ✓ | ✓ | ✓ |
| Mutate data / create tables | – | ✓ | ✓ | ✓ |
| Create / edit endpoints | – | ✓ | ✓ | ✓ |
| Mint API tokens | – | – | ✓ | ✓ |
| Invite / remove members | – | – | ✓ | ✓ |
| Manage billing | – | – | – | ✓ |
| Delete namespace | – | – | – | ✓ |
The owner role is non-transferable in the console — to hand off
ownership, the new owner must be invited as admin, then the current
owner downgrades themselves; the platform promotes the senior admin
automatically when a namespace has zero owners.
Inviting
Section titled “Inviting”Settings → Members → Invite:
- Enter email + role.
- The invitation is created and emailed (Resend if
RESEND_API_KEYis configured; otherwise the link appears in the response for manual delivery). - The invitee accepts at
console.persql.com/invite/<token>. If they’re not signed in, they sign up first. - Acceptance creates the
namespaceMemberrow and revokes the invitation token.
You can also invite via the agent — “invite jane@acme.com as editor”
— which calls propose_invite_member.
Database-level sharing
Section titled “Database-level sharing”Sometimes a namespace member should only see one specific database. Database → Sharing grants:
- Viewer — read-only on this database (overrides namespace-wide viewer).
- Editor — full read/write on this database (overrides namespace viewer).
Sharing rows live in database_share and are checked in
requireDatabaseAccess middleware after the namespace role check.
Removing a member
Section titled “Removing a member”Settings → Members → ⋮ → Remove. Sessions on the console invalidate within ~60s (next token / cookie revalidation cycle). API tokens minted by the removed member remain valid until revoked — review the API tokens page after a removal.