Hey! DB concurrent connections is a known bottleneck which is addressed by connections pool. Unfortunately by design lambda runtime virtualization does not permit to share a pool between different lambda instances. The workaround is, to setup a database reverse proxy to manage a connections pool. For example, AWS provides the RDS proxy service to absorb to facilitate the setup for RDS. In the case of Neon, we can think of a community driven OSS solution for the problem WDYT folks?
Hm, I think that it is pretty harmless to increase connection limits on our pgbouncer (or as a more long-term project – get built-in postgres connection pooler merged, there is a thread in hackers). Generally connections are some amount of memory and open files.
Or is it somehow beneficial to run some proxy/pooler on AWS side?