Hi 
We have an Elixir app in Fly that connects to a Supabase DB via PgBouncer. While trying to understand how to use the client connections available in the bouncer, 800, and how to make the most effective usage of it, we realized that health-check-based deploy strategies like rolling or canary limit the effective usage of the connections.
Take for instance the example below. Because every instance takes the same environment variables, which I use to control the size of the pool, I have to make sure the size of the pool is equal to the max connections supported by PgBouncer, divided by the maximum number of instances that can be running at the same time. In the case below that’s ~400 (800/2) (I left a bit of buffer)
So by configuring everything to make deployments succeed, I’m underusing the connections that are available. Did I get this right?
I’m looking for advise to improve this. A couple of ideas that I had were:
- Dynamically configuring Ecto’s pool size. Unfortunately, I don’t think that’s possible with Ecto.
- Using different environment variables for rollout machines (e.g. in canary machines) so that I can limit the size of the pool in those cases.
What have you seen your customers doing?
