RDS Connection Pooling and Lambda: The Cost You Don't See Coming

If you moved from a serverless PaaS to Lambda in front of RDS Postgres and started seeing FATAL: too many connections, the cause is structural, not a bug in your code: each concurrent Lambda invocation opens its own database connection, and a db.t3.micro caps out around 87 connections. The fix most teams reach for is RDS Proxy, which costs roughly $0.015 per vCPU-hour — about $11/month per vCPU if you keep it running — plus small networking overhead. Before you pay that, the honest question is whether Lambda is the right compute for a database-heavy app at all, because a single long-lived container reuses one pool and sidesteps the whole problem for a few dollars a month.

Why Lambda and connection pools fight each other #

Connection pooling works because a process stays alive and hands the same handful of TCP connections to many requests. Lambda breaks that assumption. Each execution environment handles exactly one request at a time, so if 100 invocations run concurrently, you have 100 processes, and every one of them wants its own connection. Pooling inside a single Lambda helps almost nothing — you’re pooling across requests that never share a process. The result is that a modest traffic spike can open hundreds of connections in seconds, and Postgres starts refusing new ones long before CPU is the bottleneck.

The connection ceiling scales with instance memory, not with how much work your queries do. The default max_connections on RDS Postgres is roughly LEAST(DBInstanceClassMemory/9531392, 5000), which lands near 87 on a micro, ~340 on a db.t3.medium, and higher as you climb. Idle connections aren’t free either: each one holds backend memory, so even connections doing nothing degrade the instance. This is the same wall small apps hit without Lambda, which we cover in RDS connection pooling for a small app — Lambda just makes you hit it an order of magnitude faster.

What RDS Proxy actually buys you, and what it costs #

RDS Proxy sits between your functions and the database, maintaining a warm pool and multiplexing many client connections onto far fewer database connections. For Lambda specifically this is the sanctioned pattern, because the Proxy survives across invocations even when your functions don’t. It pins connections during transactions and reuses them otherwise, which keeps your 87-connection ceiling from being the hard limit on request throughput.

The cost is predictable but not zero. Pricing is per vCPU of the underlying instance, around $0.015 per vCPU-hour, billed for every hour the Proxy exists. A two-vCPU instance running continuously is about $22/month just for the Proxy — on top of the database itself. For a side project that bills $15/month for a micro, that’s more than doubling your database line. The deeper trade-off, covered honestly in RDS Proxy vs direct connections for a small app, is that Proxy adds a hop of latency (single-digit milliseconds, usually 1–5ms) in exchange for stability under burst.

The cheaper answer is often not serverless at all #

Here’s the part most Lambda-and-RDS guides skip: if your workload is a steady web app rather than spiky, event-driven bursts, a single always-on container reuses one connection pool for its entire lifetime. A 0.25 vCPU ECS Fargate task runs around $9/month and holds, say, 10 pooled connections regardless of how many requests it serves. You get pooling for free from your framework’s driver, no Proxy charge, and no cold-start penalty on the first query of each cold environment. The economics flip toward serverless only when traffic is genuinely intermittent — long idle periods where you’d rather pay per request than for an idle container.

A reasonable rule of thumb: if your app receives traffic most hours of the day, containers win on both cost and simplicity; if it’s a webhook handler or a nightly job that spikes and then goes quiet, Lambda plus Proxy earns its keep. The cold-start math matters here too — the first database query from a freshly spun Lambda pays both the function cold start and a fresh connection handshake, which the honest numbers in Lambda cold starts in 2026 put in perspective.

How Vylara handles this without hand-tuning #

When you connect the Vylara GitHub App and point it at a repo, the Vylara agent reads your dependencies — a pg, prisma, or sequelize import flags a PostgreSQL need — and shows you a plain "Your app needs" card with a managed Postgres option around ~$15/mo, rather than making you reason about max_connections from scratch. The agent generates the container, CI, and deployment configs as a pull request from vylara-ai[bot], so you review the choices in a diff before anything is created. Nothing is provisioned on merge; the environment is created in your own AWS account on the first deploy, and the resulting connection URL is persisted so your app wires up to the database cleanly.

Because the default generated topology is a long-lived container behind a load balancer, you inherit driver-level pooling without opting into the Lambda connection problem at all. If you later need to change sizing or investigate a connection error, the in-app infrastructure chat can read your service logs and metrics and propose a fix inline — any write action waits for your approval. This is the broader pattern we lean on across AWS infrastructure deployed to your own account: pick the compute that fits the traffic shape, and let pooling fall out of the architecture instead of bolting on a Proxy to paper over the wrong choice.

The takeaway is boring on purpose. Connection exhaustion with Lambda and RDS is a predictable consequence of putting a stateless-per-request runtime in front of a connection-limited database. RDS Proxy fixes it for real money and a few milliseconds of latency; an always-on container fixes it for a few dollars and no latency if your traffic justifies staying warm. Measure your request pattern first, then choose — don’t default to serverless and discover the connection ceiling in production.