Serverless functions with a relational database
the connection-storm problem.
concurrent function instances each open connections and exhaust the database's bounded pool; fix with a connection proxy or pooler, init-phase reuse, or capped concurrency.
a connection per call.
What's really being asked
This checks whether you grasp the fundamental impedance mismatch between massively concurrent, stateless functions and a relational database's limited, stateful connection pool.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Why does a high-concurrency serverless API often crash a PostgreSQL backend, and what best addresses it?
- a.PostgreSQL cannot serve HTTP; rewrite the whole API
- b.Functions are too slow; just add more memory
- c.Each instance opens its own connection, exhausting the pool; use a proxy to multiplex onto a small poolCorrect
- d.The DLQ is misconfigured; add more retries
Why? this is the answer
Thousands of function instances each opening a connection exceed the database's bounded max_connections. A proxy or pooler multiplexes them onto a small warm pool. Memory, protocol, and DLQ changes do not address connection exhaustion.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #serverless
- #database
- #postgresql
- #rds-proxy
- #scalability
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on serverless — each one lists the topics its interview covers.
See open roles