jrmiii

It's easy to draw parallels between what's described and those dysfunctions. In case you're not familiar, this framework by Patrick Lencioni outlines five obstacles that can mess up a team’s flow: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results.

Particularly relevant to this situation: > Fear of conflict: seeking artificial harmony over constructive passionate debate

Just to warn you though, there is a tradeoff. You can also just act like an asshole and cite a culture of toxic positivity if people take issue with your behavior. The key is collaborate, productive focus on the outcomes with the other human beings involved in the endeavor.

For example, if I used the heroku api to do the equivalent of ps:scale to boot up more nodes - those new nodes (dynos in heroku parlance) could see what kind of pool members they are. I don't think there is a way to do dyno specific env vars - they apply at the app level.

If anyone tries to do a Heroku backend before I do, an alternative might be to use distinct process types in the Procfile for each named pool and ps:scale those to 0 or more.

Also, might need something like Supabase's libcluster_postgres[1] to fully pull it off.

EDIT2: So the heroku backend would be a challenge. You'd maybe have to use something like the formation api[2] to spawn the pool, but even then you can't idle them down because Heroku will try to start them back. I.e. there's no `restart: false` from what I can tell from the docs or you could use the dyno api[3] with a timeout set up front (no idle awareness)