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.

▲

SahAssar 2 hours ago | parent [-]

> 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.

	▲	drdexebtjl 32 minutes ago \| parent [-]
		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.