SproutStackSproutStack home
IntermediatePostgreSQL

Serverless functions run out of database connections

Each Lambda opens its own connection, and PostgreSQL allows 100.

The setup today

An API runs on AWS Lambda. Each function instance opens one connection to PostgreSQL when it starts and keeps it while warm. The database runs with default connection settings.

Current configuration

max_connections = 100   # the default
Lambda concurrency: up to 500 at peak
app: one connection per function instance, no pooler

What you know

  • At peak, requests fail with "sorry, too many clients already".
  • Most requests run one or two short queries and hold the connection idle the rest of the time.
  • Some code uses SET search_path and session-level advisory locks.

The new requirement

Traffic will double. The team needs the API to scale with Lambda without the database running out of connections.

Make the call

2 questions · first-try answers earn the most XP

1. What is the standard fix?
2. With transaction pooling, which part of the existing code will misbehave?
What a strong answer also covers
  • Size the pool from the database side: a few connections per CPU core is a common starting point, then measure.
  • Use transaction-level SET LOCAL instead of SET, and transaction-level advisory locks, so state ends with the transaction.
  • Protocol-level prepared statements need pooler support (PgBouncer 1.21+ with max_prepared_statements, for example).
  • Watch pool wait time: clients queuing for a connection is the new place latency hides.
Variations to think through

Change one fact and decide again. There is no single right answer here.

  • A nightly batch job needs a long session with temporary tables. Does it go through the same pool?
  • The database fails over to a replica. What do the pooler and the functions see?
  • Half the traffic is reads that could go to replicas. Where would you route them?

The background

More drills