Ask

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

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.

141 · in/drizzle-and-prisma ·

uuid v7 or bigserial primary keys for a multi tenant app doing 50k rows a day

Do both. bigserial (or identity) as the internal primary key that all your foreign keys use, plus a public_id with a unique index for URLs and the API. Joins stay narrow, external ids stay opaque, and you can change the external format later without touching your relationships.

Prefix the public id by type — inv_01hq..., org_01hq.... It costs nothing and the first time you are staring at a log line with a bare id and no idea what table it is from, you will understand.

54 · in/drizzle-and-prisma ·