> 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.
I wonder if clients send something equivalent to a User-Agent, such that the connection pooler could assign them to different pools automatically.
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.
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.
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.