Connection Pooling & Performance

Opening a database connection is expensive. It involves a TCP handshake, TLS negotiation in many deployments, authentication, memory allocation, and server bookkeeping. A connection pool keeps a bounded set of open connections and reuses them across requests.

Pool Basics

A pool checks out a connection for a query, returns it when the query completes, and queues work when all connections are busy. For long-running Node servers, start with a conservative max such as CPU cores times two plus one, then tune from real metrics.

type PoolConfig = {
  min: number;
  max: number;
  idleTimeoutMs: number;
};

export function createPoolConfig(cpuCores: number): PoolConfig {
  return {
    min: 1,
    max: cpuCores * 2 + 1,
    idleTimeoutMs: 30_000,
  };
}

Too large a pool can overload the database. Too small a pool causes queueing and timeout errors under normal traffic.

Exhaustion Symptoms

Pool exhaustion often appears as slow requests, rising queue time, too many clients, connection timeout errors, or CPU spikes on the database. Instrument pool wait time separately from query execution time so you can tell whether the database is slow or the application is waiting for a connection.

Serverless Constraints

Serverless functions can scale horizontally fast. If every function instance opens its own Prisma pool, Postgres max_connections can be exhausted quickly. PgBouncer, Prisma Accelerate, or platform-native pooling sits between functions and the database to smooth connection spikes.

export function withPrismaPoolParams(databaseUrl: string): string {
  const url = new URL(databaseUrl);
  url.searchParams.set("connection_limit", "10");
  url.searchParams.set("pool_timeout", "30");
  return url.toString();
}

This controls Prisma client-side pool behavior, but it does not replace external pooling for highly elastic workloads.

Further Learning

Search these terms to go deeper:

• “Postgres connection pooling Node.js” — pool sizing and queue behavior
• “PgBouncer serverless Prisma” — external pooling for elastic compute
• “Prisma connection_limit pool_timeout” — tuning Prisma database URLs
• “database pool exhaustion symptoms” — logs and metrics that reveal connection pressure

Connection Pooling & Performance

Opening a new database connection isn’t free — it takes real time (a handshake, authentication, memory setup). If you opened a fresh connection for every single request, your app would slow to a crawl. A connection pool solves this by keeping a set of connections open and reusing them.

How a pool works

Think of it like a small fleet of taxis waiting outside a building. A request “checks out” a connection, uses it, and returns it to the pool when done — rather than everyone hailing a brand-new taxi from scratch each time.

{ min: 1, max: 10, idleTimeoutMs: 30_000 }

Too few connections and requests queue up waiting for a free one. Too many and you overload the database itself. Start conservative and tune based on real traffic.

Signs your pool is too small

If you see requests getting slower under load, or errors like “too many clients,” that’s often pool exhaustion — every connection is busy, and new requests are stuck waiting in line.

The serverless trap

In one sentence

A connection pool reuses a limited set of open database connections instead of creating a new one per request — size it carefully (not too big, not too small), and in serverless environments, use an external pooler to avoid exhausting your database’s connection limit.

Want to go deeper?

Switch to Expert mode above for pool sizing formulas and Prisma’s connection_limit/pool_timeout settings.