# Supabase CLI: permission denied to alter role "cli_login_postgres"

TL;DR: the CLI manages a helper role named cli_login_postgres for pooled connections, and the current database user is not allowed to alter it - usually because a stale copy of the role already exists from an older CLI version, or the user lacks role-admin rights. Connect as a superuser (or the project owner credentials), drop the stale cli_login_postgres role if it exists, and re-run the push so the CLI recreates it cleanly. If you cannot get superuser, ask the project owner to run the push once.

```text
permission denied to alter role "cli_login_postgres"
```

## Steps

1. Connect to the database as the project owner / superuser (dashboard SQL editor works).

2. Check for the stale role and drop it: `DROP ROLE IF EXISTS cli_login_postgres;`. Expected: the role is gone.

3. Re-run the CLI command (`supabase db push`). Expected: the CLI recreates its helper role without the permission error.

4. If you are not the owner, have the owner run the push once, or grant your user the rights to manage roles. Do not hand-edit the role's password by hand.

## When this applies

- the exact `permission denied to alter role "cli_login_postgres"` message on db push
- projects where an older CLI version previously created the helper role
- team members pushing with non-owner database users

## When it doesn't

- password authentication failed - that is a credential problem, not a role problem
- RLS policy violations in your migration SQL - those fail on tables, not roles
- pooler SCRAM errors - those fail before any role statement runs

## Compatibility

Supabase CLI db push; the cli_login_postgres helper role; owner-level database access for the fix. Verified against the community Supabase migrations guide.

## Variant phrasings

- supabase permission denied to alter role cli_login_postgres
- supabase db push alter role error
- supabase cli_login_postgres fix

## Root cause

The CLI needs a predictable login role for its pooled migration connection and tries to ensure it on every push. A leftover role owned by someone else, or a connecting user without CREATEROLE, turns that ensure step into a permission error.

## Edge cases

- dropping the role mid-push from another session can wedge a concurrent push; coordinate with the team
- managed Supabase projects: the owner credentials are in the dashboard database settings
- after dropping, the next push recreates the role automatically; nothing else to configure