This exists, its called a user. You just use different database users for this.

I was thinking of something that only exists at the pool level.

Every new version of your app has the potential to change behavior in a way that would affect the previous version if the connection was recycled during a progressive rollout.

But I don’t think I would want to create a real database user for every version of the app.

I suppose the connection pooler could map versioned users to the same real user, and use separate pools, but a dedicated UA field is probably better.

> But I don’t think I would want to create a real database user for every version of the app.

Why not? Database users are (usually) not expensive, and with groups you can give access to a group you just add the user to.

Adding this logic to the connection pooler seems more complicated.

Because it means connecting to the database to provision a new user on every deploy.

Also because it doesn’t really concern the database, it concerns the pooler.

Connection poolers already maintain multiple pools, it would not be complicated at all.

Can also use different database names since pgbouncer lets you remap that