Postgres gives every connection its own process and a fixed maximum, while serverless platforms create a new instance, and a new connection, for each concurrent request. The result is the classic launch-day error. How the limits are set on RDS and Supabase, what a pooler does, and the transaction-mode catch.
A traditional server opens a pool of perhaps 10 connections and shares them across thousands of requests. A serverless function cannot share: each concurrent instance holds its own. At 300 concurrent requests you can have 300 connections, and PostgreSQL's default max_connections is 100.
PostgreSQL runs a server process per connection, so each costs memory even when idle.
On RDS for PostgreSQL the default is LEAST({DBInstanceClassMemory/9531392}, 5000): about 110 connections per GiB of memory, less what RDS reserves. Small instances allow a few dozen to a couple of hundred.
Raising max_connections without more memory swaps a connection error for memory pressure.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
A pooler accepts many client connections and multiplexes them onto a few real ones. In transaction mode, a real connection is lent out for one transaction and returned, so hundreds of functions can share twenty connections.
Create the database client outside the handler so a warm instance reuses its connection.
Set the pool size inside each function to 1 or 2. Ten per instance multiplies the problem.
Set statement and idle timeouts so one stuck query does not hold a connection indefinitely.
Graph active connections and alert well below the limit.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Backups for a Small Team: RPO, RTO and the Restore You Have Not Tested
A backup you have never restored is a hope. The two numbers that define a backup plan, which failures each kind of backup covers (including a compromised account and a bad migration), the RDS retention defaults that surprise people, and a quarterly restore drill that takes an afternoon.
Read
Row-Level Security: The Check Between Your Users' Data and Everyone Else
Apps on Supabase, Firebase and similar platforms let the browser talk to the database directly. That is fine only if the database enforces who sees what, because anyone can call the same API without your UI. How row-level security works, the gaps that catch people (views, functions, storage), and a ten-minute test.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.