JRjrmiii·Dec 6, 2023
Ah, that makes a lot of sense - I think the FLAME.Parent{} approach may enable backends that wouldn't be possible otherwise.
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
Read the rest
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)
[1] https://github.com/supabase/libcluster_postgres
[2] https://devcenter.heroku.com/articles/platform-api-reference...
[3] https://devcenter.heroku.com/articles/platform-api-reference...