Connection Proxy

Databases handle connections expensively — each typically costs a process or thread and a fixed amount of memory — so a managed instance has a connection limit in the hundreds while the application tier may want thousands.

The mismatch is created by architecture. Serverless functions scale to hundreds of concurrent instances, each opening its own connection. Containers multiply pool size by replica count. Both exhaust the limit and produce connection-refused errors that look like a database outage.

A proxy multiplexes: clients connect to it freely, and it maintains a small pool of real database connections, handing them out per transaction rather than per client.

Two things to understand before adopting one. Pooling mode changes semantics — transaction-level pooling (the efficient mode) breaks session-scoped features such as prepared statements, temporary tables, advisory locks and SET variables, because consecutive statements may run on different backend connections. Applications sometimes need changes.

And a proxy adds a hop, a small latency cost, and a component that must itself be highly available — though managed proxies additionally shorten failover time by holding client connections open while the database fails over underneath, which is a real secondary benefit.