still getting too many clients already on the pooled 6543 string at 120 concurrent Connection Pooling

The pooler is not the only pool in the picture. Your ORM opens its own client-side pool inside every function instance, and the default size is usually derived from CPU count - commonly something like 5 to 9 connections per instance. 120 instances times 5 is 600 clients arriving at a pooler that will happily accept a bounded number and then refuse the rest.

Append the limit to the pooled URL:

postgres://...:6543/db?pgbouncer=true&connection_limit=1

One connection per instance is correct for serverless. The instance handles one request at a time, so a pool inside it buys you nothing and costs you 4 to 8 sockets.

While you are there, confirm the host really is the pooled one. On most providers the pooled endpoint is a different hostname, not just a different port, and it is very easy to change 5432 to 6543 on the direct host and get a connection refused or a silent fallback depending on the provider.

Also check whether something else in the same deployment is quietly using the direct connection. Migrations, a seed script, a health check, or the ORM itself for schema introspection - several of them insist on a direct URL and will use DIRECT_URL if it exists in the environment. If a migration runs on deploy while the burst is happening, that is 20 direct connections arriving at the worst moment.

Easiest way to prove it: select count(*), application_name from pg_stat_activity group by 2 during the burst. If you see anything other than what you expect, there is your second client.

Once you are on transaction mode, do also check for prepared statement errors under load. Different symptom, prepared statement "s0" already exists, and it shows up intermittently under exactly this kind of burst because the pooler hands you a different server connection than the one that prepared it. Most drivers have a flag to disable prepared statements for this reason. Not your current bug but you will meet it next week.

One more ceiling people forget: the pooler has its own limit, and on smaller plans it is lower than you would guess. 120 concurrent invocations each holding a client connection can exceed the pooler's client limit even at one connection each - at which point the fix is not on your side, it is a plan size or a queue in front of the burst. Worth reading which of the two numbers you are actually hitting before buying anything.

For what it is worth, 90ms functions and a 120 burst is exactly the profile where an HTTP-based database driver stops being a novelty. No sockets to run out of, no pool to size, and the connection ceiling stops being something you think about. Bigger change than a query string parameter, but it deletes the entire category.

Every serverless database story is the same story: something you did not know was a pool was a pool.