Prisma Postgres

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the Postgres setup I actually need instead of a managed serverless one — and start with the problem it solves, because you may not have it.

**The problem is connections.** A serverless runtime opens one per request, and Postgres allocates a process per connection, so a few hundred concurrent requests exhaust a database that would otherwise be idle. If your application is a long-running process on one machine, you do not have this problem and none of the machinery below is needed.

STACK
- Postgres on a machine you rent, or SQLite on the application's own machine if the shape allows
- PgBouncer in transaction mode for pooling. Do not write a pooler
- Node 20+ for the application
- Caddy in front

IF YOU ARE SERVERLESS
- PgBouncer in transaction pooling mode, which multiplexes many client connections onto a few real ones. That is the whole fix and it is a configuration file
- **Transaction mode breaks anything that spans statements**: prepared statements, session variables, advisory locks, LISTEN and NOTIFY. Know which your driver uses and disable prepared statements if it does, or you will get intermittent errors nobody can reproduce
- Set the pool size from the database's actual capacity rather than optimistically, and monitor waiting clients
- An HTTP query endpoint only if a runtime genuinely cannot open a socket. Then it is a thin authenticated proxy that parameterises everything and never takes SQL from a client

IF YOU ARE NOT SERVERLESS
- One connection pool in the application process, sized to the database. That is a library call and there is nothing else to do
- Consider whether you need Postgres at all. SQLite on the application's own machine turns every read into a local file read — microseconds, no network, no pool — and handles more than people expect

THE PART THAT MATTERS MORE THAN POOLING
- **Continuous archiving** of the write-ahead log to object storage, giving a recovery point measured in seconds rather than a night
- Nightly snapshots with a stated retention
- **A restore rehearsed onto a clean machine, with the time written down.** That number is your recovery time and almost nobody knows theirs
- A verification job, because a backup failing quietly for three weeks looks exactly like one that works
- An alert on the age of the last successful backup

MIGRATION DISCIPLINE
- Backwards-compatible in both directions across a deploy: add a column, deploy, write to it, backfill in batches, read from it, and remove the old one in a later release. Never two steps together
- Test every migration against a restored copy of production first

WATCHING IT
- Connection count against the limit, waiting clients in the pooler, slow queries with their plans, replication lag, and free disk with an alert well before it matters

WHAT MATTERS MOST
Work out whether you have the connection problem before solving it. If you do, PgBouncer in transaction mode is a configuration file; if you do not, the whole category is answering a question you did not ask.