prisma opened 190 connections on neon during a spike and connection_limit=1 didn't help Serverless Driver

connection_limit caps the pool inside one process. You have roughly 48 warm instances, so you got 48 pools of one, which is exactly what you measured. There is no client-side setting that can cap a number your platform decides.

Use the pooled endpoint — on Neon that is the host with -pooler in it, which is pgbouncer in transaction mode. Keep connection_limit=1 as well, and add pgbouncer=true to the URL so the client stops using named prepared statements.

What you give up in transaction mode: session state. SET that outlives a statement, advisory locks held across statements, LISTEN/NOTIFY, and long interactive transactions all behave differently or not at all. For CRUD over HTTP requests, none of that matters.

Also confirm you are not constructing a client per request. The classic version of this is dev-only (HMR creating a new client on every save until the db falls over) but the serverless version is real too — a client created inside a handler instead of at module scope means a fresh pool per invocation and no reuse across warm calls.

Different angle: for read-heavy paths use the HTTP driver and hold no connection at all. Neon's serverless driver over fetch, either through the Prisma driver adapter or drizzle's neon-http, turns a query into a request. No pool, nothing to exhaust, works on edge runtimes.

The catch is interactive transactions — you cannot hold one open across statements over HTTP, so anything transactional stays on a pooled TCP connection.

Your 10s timeouts were not the database. pool_timeout=20 means a request waits up to 20 seconds for a free slot in a pool of size 1, so you converted connection errors into a queue. That is usually the right trade but you have to know you made it.

Just size the compute up, max_connections scales with it and you stop thinking about pools.