3 ms·
> 4. Use separate bouncers for each application that might be different (extension of #1) I wonder if clients send something equivalent to a User-Agent, such t
by drdexebtjl 4mo ago
> 4. Use separate bouncers for each application that might be different (extension of #1)
I wonder if clients send something equivalent to a User-Agent, such that the connection pooler could assign them to different pools automatically.
- tpetry 4mo agoThis exists, its called a user. You just use different database users for this.
- drdexebtjl 4mo agoI 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 3mo ago> 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 3mo agoBecause 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.
- nijave 4mo agoCan also use different database names since pgbouncer lets you remap that