> postgres roles & traffic
PlanetScale Postgres uses real Postgres roles as credentials: create one per app or teammate with exactly the privileges it needs (pg_read_all_data, pg_write_all_data, or full postgres admin), expire them with TTLs, and reset or reassign them without downtime. Traffic Control adds budgets that cap how much load a class of queries may consume — a brake pedal for noisy neighbors.
// postgres roles & traffic
9 commands$ pscale role create mydb main analytics-ro --inherited-roles pg_read_all_data$ pscale role create mydb main migration-admin --inherited-roles postgres$ pscale role create mydb main hotfix-debug --inherited-roles pg_read_all_data --ttl 1h$ pscale role list mydb main$ pscale role reset mydb main <role-id>$ pscale role reset-default mydb main$ pscale role reassign mydb main <role-id> --successor app-rw$ pscale traffic-control budget create mydb main --name batch-jobs --capacity 2000 --rate 20 --mode warn$ pscale traffic-control rule create mydb main <budget-id> --fingerprint 'select * from analytics_events where ...'// faq
How do I make a read-only credential for a Postgres branch?
`pscale role create <db> <branch> analytics --inherited-roles pg_read_all_data`. The connection credentials print once at creation. Use pg_write_all_data for writers and postgres for admin-level access, and comma-separate to combine.
What happens when a role's TTL expires — does my app just die?
The role stops authenticating, so yes, connections fail. For long-lived apps use no TTL and rotate deliberately with role reset (new password, same role). TTLs shine for temporary access — a contractor, a debugging session, a one-off script — and `pscale role renew` extends one that's about to lapse.
Why can't I delete a role?
Postgres won't drop a role that still owns tables or other objects. Run `pscale role reassign <db> <branch> <role-id> --successor <other-role>` to transfer ownership first, then delete. This is standard Postgres semantics surfaced through the CLI.