Serverless functions with a relational database

WHAT THIS TESTS This checks whether you grasp the fundamental impedance mismatch between massively concurrent, stateless functions and a relational database's limited, stateful connection pool.

A GOOD ANSWER COVERS The core challenge is connection management. PostgreSQL allocates memory per connection and supports a bounded maximum, often only a few hundred. Functions scale horizontally to potentially thousands of concurrent execution environments, and if each opens its own connection the database hits max_connections, returning errors and degrading. Functions are also short-lived, so naive code opens and closes a connection per request, paying TCP and TLS handshake cost every time. The primary fix is a managed connection proxy or pooler such as RDS Proxy or PgBouncer that sits between functions and the database, maintaining a small warm backend pool and multiplexing many client connections onto it. Complementary measures: declare the client in the init phase so a warm environment reuses one connection across invocations; cap function reserved concurrency to bound total connections; use IAM auth through the proxy; or pick a serverless-native database with an HTTP data API that removes persistent connections entirely.

COMMON WRONG ANSWERS Opening a fresh connection inside the handler on every call. Ignoring max_connections and assuming the database scales like the functions. Putting a pooler inside each function, which cannot share state across instances. Forgetting that idle warm environments still hold connections. Believing read replicas alone solve a write-path connection storm.

LIKELY FOLLOW-UPS Why does pooling inside a single function not help? How does RDS Proxy pin connections during transactions? How do you bound total connections? What does a data API change about the model?

ONE CONCRETE EXAMPLE A traffic spike scales the function to 800 concurrent instances; the database caps at 200 connections and starts rejecting them. Introducing RDS Proxy multiplexes those 800 clients onto a warm pool of 100 backend connections, and capping reserved concurrency guarantees the ceiling is never exceeded, so the database stops erroring under load.