AWS Lambda Provisioned Concurrency vs. RDS Connection Limits

When serverless scales fast and your database can't keep up: a real-world debug story.

The Scenario

During an early-access product rollout, we enabled provisioned concurrency on an AWS Lambda function to reduce cold starts and ensure instant responsiveness. We set it to 100, assuming readiness for a surge of traffic.

The Problem

Almost immediately, our RDS PostgreSQL database began throwing connection errors. Lambda invocations were throttling at the database layer, causing retries, latency spikes, and user-facing failures.

The Diagnosis

It turned out the RDS connection pool was limited to 50 max connections, while Lambda — with provisioned concurrency of 100 — was creating new database clients at scale. Each Lambda container was consuming a connection, and RDS was simply overwhelmed.

The Fix

• ✅ Reduced provisioned concurrency to match realistic RDS thresholds
• ✅ Implemented a RDS Proxy to manage connection pooling effectively
• ✅ Switched to a singleton DB client strategy using Lambda container reuse

Lessons Learned

This issue was a classic case of mismatch between scaling compute and fixed backend infrastructure. AWS gives you the power to scale Lambda instantly, but your database won’t magically scale with it. Always align provisioned concurrency with DB capabilities — or introduce a managed proxy layer.

Bonus Tip: If you're using frameworks like Spring Boot or Sequelize, be mindful of default connection settings — they can sneak in per-request pool creation.

Need help tuning your Lambda performance and backend architecture? Let's chat.