Adding additional tools to solve a most basic system function - connecting to a database - seems to add extra complexity and potential points of failure that don’t seem to be necessary.
I would first go back to the original problem.
Why is the number of connections a problem?
Why do you think the number was unusually high?
Keep in mind that AppSheet is a distributed system. EVERY user has its own FULL copy of the app and data. AppSheet’s servers may combine some of that functionality but since each user is performing functions at different times to different parts of the app, a set of connections will be basically by user.
If you haven’t already, you might investigate the usage of server caching in tables that do not change often to minimize the back an forth to the database.
Long story short, when AppSheet would sync it would open a connection for every table, and those connections would persist for several minutes. This quickly overwhelmed the available db connections.
You mention PgBouncer - this is what Supabase used to use, and I never had any issues with it. That said, if possible I would avoid using poolers for your appsheet <> postgres connection.
Some insights.
Nowadays Supabase uses it’s Supavisor as pooler but when you are a paid customer you can use pgBouncer in your own instances.
That means that paying customers, which has also purchased the IPv4 addon must have no issues at all with AppSheet’s Postgres connection if configured properly