---
title: "Prisma Connection Pooling"
slug: "prisma-pooling"
category: "backend"
tags: ["backend", "prisma", "pooling", "postgres", "serverless", "pgbouncer", "performance"]
status: "stable"
last_updated: 2026-05-29
summary: "Choose between Prisma Accelerate, PgBouncer, and direct connections; configure pgbouncer=true; avoid transaction-mode pitfalls in serverless."
related:
  [
    "[[backend/prisma]]",
    "[[backend/postgres]]",
    "[[backend/prisma-client]]",
    "[[backend/prisma-transactions]]",
    "[[backend/prisma-migrations]]",
    "[[backend/prisma-driver-adapters]]",
    "[[comparisons/prisma-vs-drizzle]]",
    "[[ops/hostinger-vps]]",
  ]
---

## Overview

Every `PrismaClient` instance maintains an internal connection pool. By default, Prisma sizes the pool based on CPU count and keeps connections open for the lifetime of the process. In long-running servers this works. In serverless and edge runtimes, each function invocation may spawn a new client, exhausting [[backend/postgres]]'s connection limit in minutes. Connection pooling sits between the application and Postgres to multiplex many client connections onto a small number of database connections. Choose the right pooling strategy for your runtime before you scale.

## Use Prisma Accelerate for serverless and edge runtimes

Prisma Accelerate is a managed connection pooler and global cache offered by Prisma. It runs at the edge and keeps a warm pool of connections to your database.

```ts
// Accelerate runs over HTTP, so it does not need a database driver adapter.
import { PrismaClient } from "./generated/prisma/client"
import { withAccelerate } from "@prisma/extension-accelerate"

const prisma = new PrismaClient().$extends(withAccelerate())
```

- Use Accelerate when you deploy on Lambda, Vercel Functions, Cloudflare Workers, or any platform where the function process does not persist between requests.
- Accelerate is the one path where `new PrismaClient()` takes no driver adapter: the Accelerate extension supplies the connection. Every direct-database client in Prisma 7 needs an adapter. See [[backend/prisma-driver-adapters]].
- Accelerate also caches query results at the edge. Enable it per query: `prisma.user.findUnique({ ..., cacheStrategy: { ttl: 60 } })`.
- Accelerate does not support interactive transactions with custom isolation levels on all plans. Verify the feature matrix before relying on it. See [[backend/prisma-transactions]] for transaction options.

## Use PgBouncer for long-running Node servers

PgBouncer is a lightweight connection pooler you self-host in front of Postgres. It is the standard choice for VPS and container workloads.

```
# .env (long-running server behind PgBouncer)
DATABASE_URL="postgresql://user:pass@pgbouncer-host:5432/db?pgbouncer=true&connection_limit=1"
```

- `?pgbouncer=true` disables Prisma's own prepared-statement caching, which is incompatible with PgBouncer's transaction mode.
- `connection_limit=1` tells Prisma to open only one connection per client instance. PgBouncer multiplexes many such connections onto fewer database connections.
- PgBouncer in transaction mode is the correct choice for most Prisma setups. Session mode defeats the purpose of pooling when you have many short-lived queries. See [[ops/hostinger-vps]] for a typical PgBouncer deployment.

## Know what breaks in PgBouncer transaction mode

Transaction mode resets server state between transactions. Several Postgres features rely on session state and break.

- `SET LOCAL` and `SET SESSION` are not safe. Prisma uses `SET LOCAL` internally for some operations.
- Advisory locks (`pg_advisory_lock`) require session affinity. They silently fail in transaction mode.
- Prepared statements are not reusable across connections. `?pgbouncer=true` disables Prisma's prepared-statement cache to handle this.
- `LISTEN`/`NOTIFY` requires a persistent session. Use Prisma Pulse or a dedicated non-pooled connection for change data capture.

If you need any of these features, configure a second connection string that bypasses PgBouncer and use it only for those operations.

## Set `connection_limit` and `pool_timeout` explicitly

With a driver adapter, the underlying database driver owns the pool, so you set limits on the connection string passed to the adapter. The `pg` pool used by `@prisma/adapter-pg` reads `connection_limit` and `pool_timeout` from the URL.

```ts
import { PrismaPg } from "@prisma/adapter-pg"

const adapter = new PrismaPg({
  connectionString: `${process.env.DATABASE_URL}&connection_limit=5&pool_timeout=10`,
})
const prisma = new PrismaClient({ adapter })
```

- Set `connection_limit` to a value that matches PgBouncer's `max_client_conn` divided by the number of app instances. Without a cap, a busy process can open more connections than Postgres allows.
- Set `pool_timeout` (in seconds) to fail fast when the pool is exhausted rather than queuing indefinitely.
- Monitor `pg_stat_activity` on [[backend/postgres]] to see actual connection counts and idle time. See [[backend/prisma-driver-adapters]] for adapter options.

## Avoid cold-start connection exhaustion in serverless

Each cold Lambda or serverless container creates a new `PrismaClient`. If 100 containers start simultaneously, they attempt 100 connections to Postgres. Without a pooler, Postgres hits `max_connections` and starts refusing.

```ts
// Lambda: explicit connect/disconnect to return the connection promptly.
export const handler = async (event: unknown) => {
  await prisma.$connect()
  try {
    return await handleEvent(event)
  } finally {
    await prisma.$disconnect()
  }
}
```

- Explicit `$disconnect` returns the connection to the pool (or closes it for direct connections) before the container goes idle.
- With Prisma Accelerate or PgBouncer, the pooler absorbs the burst. Direct connections to Postgres do not. See [[backend/prisma-client]] for the full Lambda lifecycle pattern.

## Use Pulse for real-time change data capture

Prisma Pulse streams database change events over a persistent WebSocket. It requires session-level `LISTEN`/`NOTIFY`, which bypasses PgBouncer.

```ts
const subscription = await prisma.user.stream()

for await (const event of subscription) {
  console.log(event.action, event.created)
}
```

- Pulse manages its own connection to Postgres, separate from the query pool.
- Use Pulse for webhooks, cache invalidation, and audit trails where you need real-time row-level events.
- Do not use Pulse as a general-purpose message queue. For fan-out workloads, pair it with a proper queue service.

## Related

- [[backend/prisma]]
- [[backend/postgres]]
- [[backend/prisma-client]]
- [[backend/prisma-transactions]]
- [[backend/prisma-migrations]]
- [[comparisons/prisma-vs-drizzle]]
- [[ops/hostinger-vps]]