Database Connection Pooling in Serverless Environments: PgBouncer, Neon, and Hyperdrive Compared

PostgreSQL has a hard ceiling on simultaneous connections. By default it is 100. Every connection consumes around 5-10 MB of shared memory and a backend process on the server. This is fine when you have a handful of long-running application servers with stable connection pools. It falls apart the moment you move to serverless.

In a serverless environment, every function invocation is a separate process. There is no shared state between invocations, so there is no shared connection pool. Each cold start opens a new connection to Postgres. At low traffic this is invisible. At moderate traffic you hit too many connections errors. At any real scale you are either failing requests or paying for a much larger database instance just to handle the connection overhead.

This article covers why the problem exists, how the three dominant solutions approach it architecturally, and how to choose between them for a given production setup.

Why Serverless Breaks the Standard Pooling Model

Traditional web servers manage database connections through a process-level pool. A Node.js app using pg-pool opens a fixed number of connections on startup, reuses them across requests, and closes them when the process shuts down. The pool is bounded by the number of running processes, which is bounded by your server count. A fleet of 10 servers with a pool size of 10 means 100 total connections, predictable and controlled.

Serverless inverts this. The runtime manages concurrency, not you. At any given moment you might have 0 or 500 concurrent function instances. Each one tries to connect to Postgres. There is no central coordinator to enforce a limit. The connections accumulate until Postgres rejects them.

The naive fix is to simply raise max_connections in Postgres. This helps briefly but scales poorly. Each connection is not free: Postgres spawns a backend process per connection, and those processes share a fixed amount of shared_buffers and work_mem. Raising to 1000 connections on a small instance means each connection gets a fraction of the resources, query performance degrades, and you often end up slower than you were at 100 connections.

The correct fix is to put a pooler between your serverless functions and Postgres. The pooler maintains a small, stable set of real Postgres connections and multiplexes many client connections across them.

// What happens without a pooler: every invocation opens a fresh connection
import { Pool } from "pg";

// This creates a new pool (and a new connection) on every cold start
// In serverless, "cold start" = "every invocation" in the worst case
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 1, // pointless limit; each lambda has its own pool
});

export const handler = async (event: APIGatewayEvent) => {
  const client = await pool.connect();
  try {
    const result = await client.query("SELECT * FROM users WHERE id = $1", [
      event.pathParameters?.id,
    ]);
    return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
  } finally {
    client.release();
  }
};
// At 200 concurrent invocations: 200 connections open simultaneously.
// Postgres limit: 100. Result: connection errors.

PgBouncer: Self-Hosted, Maximum Control

PgBouncer is the oldest and most battle-tested solution. It is a lightweight TCP proxy written in C that runs as a separate process, accepts Postgres connections from clients, and routes them to a smaller pool of real Postgres connections.

How It Works

PgBouncer operates in one of three pooling modes:

Session pooling: A client gets a dedicated server connection for the duration of its session. This is essentially the same as no pooling from a connection count perspective. Not useful for serverless.

Transaction pooling: A client holds a server connection only for the duration of a transaction. Between transactions, the server connection goes back to the pool. This is the mode you want for serverless. One hundred Postgres connections can serve thousands of concurrent clients as long as no single transaction holds a connection for a long time.

Statement pooling: The most aggressive mode. Server connections are released after each statement, not each transaction. This breaks anything that uses multi-statement transactions, prepared statements, or SET session variables. Almost never used in practice.

Transaction pooling is the right mode for serverless, but it comes with real constraints. Anything that depends on session state breaks: SET search_path, advisory locks, LISTEN/NOTIFY, prepared statements (in the protocol sense), and COPY streaming. Most application code is fine, but you need to audit carefully.

// PgBouncer connection configuration
// Your app connects to PgBouncer, not directly to Postgres
const pool = new Pool({
  host: "pgbouncer.internal", // PgBouncer host
  port: 6432,                 // PgBouncer default port (not 5432)
  database: "mydb",
  user: "app_user",
  password: process.env.DB_PASSWORD,
  max: 10,                    // Connections from this process to PgBouncer
  // PgBouncer then maps these to its own pool of real Postgres connections
});

// One gotcha: prepared statements break in transaction mode.
// Use simple query protocol instead, or disable prepared statements.
// With node-postgres, set statement_timeout at query level, not session level.
const result = await pool.query({
  text: "SELECT * FROM orders WHERE user_id = $1 AND created_at > $2",
  values: [userId, since],
  // Do NOT cache this as a named prepared statement
});

Deployment and Operational Reality

PgBouncer is typically deployed as a sidecar container, a dedicated small VM, or a managed service (AWS RDS Proxy uses PgBouncer under the hood). The operational surface is non-trivial: you are now running and monitoring another piece of infrastructure. You need to configure:

• pool_size per database/user combination
• max_client_conn (total clients PgBouncer will accept)
• server_lifetime and server_idle_timeout to recycle stale connections
• TLS between PgBouncer and Postgres, and between clients and PgBouncer separately
• Health checks, restart policies, and alerting on pool exhaustion

For teams already running Kubernetes or ECS, this is manageable. For teams trying to avoid all infrastructure, this is a significant overhead.

Performance Characteristics

PgBouncer adds roughly 0.5-2ms of latency per query in transaction mode, mostly from the proxy hop. This is negligible for most applications. The real gain is in throughput: you can sustain thousands of concurrent clients with tens of real Postgres connections.

Neon: Pooling Built Into the Platform

Neon is a serverless Postgres provider with connection pooling built into the platform itself. Every Neon project gets a pooled connection string alongside the direct connection string. The pooler is PgBouncer running in transaction mode, managed by Neon.

What This Means in Practice

You use a different connection string for serverless workloads:

import { neon } from "@neondatabase/serverless";

// Use the pooled connection string for serverless functions
// Format: postgres://user:pass@ep-xxx-pooler.us-east-2.aws.neon.tech/dbname
const sql = neon(process.env.DATABASE_URL_POOLED!);

export default async function handler(req: Request): Promise<Response> {
  // neon() is an HTTP-based client that works without persistent TCP connections
  // Each call is a single round-trip, no connection state maintained
  const users = await sql`
    SELECT id, email, created_at
    FROM users
    WHERE active = true
    ORDER BY created_at DESC
    LIMIT 50
  `;
  return Response.json(users);
}

The @neondatabase/serverless driver has two modes. The neon() function uses HTTP to execute queries, which means zero connection overhead per invocation. It is stateless by design. The Pool and Client classes from the same package use WebSockets and can maintain connections across invocations in environments that support it (like Cloudflare Workers with Durable Objects or long-lived Edge functions).

Architecture Trade-offs

The HTTP driver is elegant for simple queries but loses some Postgres features. You cannot stream large result sets. Transaction support exists but is limited to a single HTTP request containing the full transaction. For anything more complex, you drop down to the WebSocket-based client, which reintroduces connection state.

Neon’s serverless architecture also “autosuspends” branches that are idle for a period. Cold starts after suspension take 500ms-3s to wake the compute node. This matters for latency-sensitive workloads. For background jobs, batch processing, or low-traffic applications, it is usually acceptable.

import { Pool } from "@neondatabase/serverless";
import ws from "ws";
import { neonConfig } from "@neondatabase/serverless";

// For Node.js environments, configure WebSocket support
neonConfig.webSocketConstructor = ws;

// Use Pool for transaction support
const pool = new Pool({
  connectionString: process.env.DATABASE_URL_POOLED,
});

async function transferFunds(
  fromId: string,
  toId: string,
  amount: number
): Promise<void> {
  const client = await pool.connect();
  try {
    await client.query("BEGIN");
    await client.query(
      "UPDATE accounts SET balance = balance - $1 WHERE id = $2",
      [amount, fromId]
    );
    await client.query(
      "UPDATE accounts SET balance = balance + $1 WHERE id = $2",
      [amount, toId]
    );
    await client.query("COMMIT");
  } catch (err) {
    await client.query("ROLLBACK");
    throw err;
  } finally {
    client.release();
  }
}

When Neon Makes Sense

Neon solves the operational problem completely. You do not manage a pooler, you do not configure pool_size, you do not worry about PgBouncer health. The trade-off is that you are committed to Neon as your Postgres provider. Migration off Neon means migrating your pooling strategy simultaneously.

Cloudflare Hyperdrive: Pooling at the Edge

Cloudflare Hyperdrive is a different approach to the same problem. Instead of putting a pooler next to your database, Hyperdrive puts it inside Cloudflare’s network. Your Worker connects to Hyperdrive locally (within the edge network), and Hyperdrive maintains a persistent pool of connections to your database, wherever it lives.

The Core Idea

Cloudflare Workers run in 300+ edge locations. A Worker in Frankfurt connecting to a Postgres database in us-east-1 faces 100-150ms of round-trip latency just for the TCP handshake, before any query runs. Multiply that by the number of round-trips in a connection setup (TLS handshake, Postgres authentication, query, response) and a simple query can cost 400-600ms.

Hyperdrive solves two problems simultaneously: it pools connections (so Workers do not open new Postgres connections per invocation) and it co-locates the pool close to your database (so the high-latency leg of the connection is internal to Cloudflare’s network, not per-request).

// wrangler.toml
// [[hyperdrive]]
// binding = "HYPERDRIVE"
// id = "your-hyperdrive-id"

interface Env {
  HYPERDRIVE: Hyperdrive;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Hyperdrive provides a connection string that points to the local pooler
    // The actual Postgres connection is maintained by Hyperdrive's infrastructure
    const { Pool } = await import("pg");
    const pool = new Pool({
      connectionString: env.HYPERDRIVE.connectionString,
      // Keep max low: each Worker instance should use few connections to Hyperdrive
      max: 5,
    });

    const client = await pool.connect();
    try {
      const result = await client.query<{ id: string; name: string }>(
        "SELECT id, name FROM products WHERE active = true LIMIT 20"
      );
      return Response.json(result.rows);
    } finally {
      client.release();
      await pool.end();
    }
  },
};

Caching Layer

Hyperdrive also caches query results for read-heavy workloads. You can annotate queries with cache hints. This is distinct from the pooling feature and optional, but for read-heavy APIs it can eliminate database round-trips entirely for frequently accessed data.

// Hyperdrive query caching (via the fetch API integration)
// This is separate from the pg driver path, using Hyperdrive's HTTP interface
const result = await env.HYPERDRIVE.fetch(
  new Request("https://hyperdrive/query", {
    method: "POST",
    body: JSON.stringify({
      query: "SELECT id, name, price FROM products WHERE category = $1",
      params: ["electronics"],
      // Cache this result for 60 seconds
      // Hyperdrive serves cached results without hitting Postgres
    }),
  })
);

Constraints

Hyperdrive only works within Cloudflare Workers. It is not available for Lambda, Cloud Run, or any other serverless platform. This is a hard constraint. If you are running a mixed environment (some Workers, some Lambda), Hyperdrive only helps the Workers side.

Hyperdrive also requires your database to be reachable from Cloudflare’s network. Databases inside a private VPC with no public endpoint need Cloudflare Tunnel or a jump host to be accessible.

Comparison Table

Dimension	PgBouncer (self-hosted)	Neon Built-in Pooler	Cloudflare Hyperdrive
Operational overhead	High (you run it)	None	Low (Cloudflare manages)
Works with any Postgres	Yes	No (Neon only)	Yes (any reachable Postgres)
Works with any serverless platform	Yes	Yes	No (Workers only)
Transaction mode pooling	Yes	Yes	Yes
Connection latency reduction	No	No	Yes (edge co-location)
Query caching	No	No	Yes (optional)
Prepared statements support	No (transaction mode)	No (HTTP driver)	Limited
Cold start latency	None (always on)	Yes (autosuspend)	None
Cost	Infrastructure cost	Included in Neon pricing	Included in Workers pricing
Session-level features	No	No	No

Production Considerations

Connection String Management

Regardless of which pooler you use, keep pooled and direct connection strings separate. Use the pooled string for all application traffic. Reserve the direct string for migrations, schema introspection tools, and administrative tasks that require session-level features.

// config/database.ts
export const dbConfig = {
  // For application queries: goes through the pooler
  pooled: process.env.DATABASE_URL_POOLED!,
  // For migrations and admin: direct connection
  direct: process.env.DATABASE_URL_DIRECT!,
};

// Use direct connection for Drizzle or Prisma migrations
// DATABASE_URL in your migration scripts should be the direct URL

Monitoring Pool Health

The biggest operational risk with connection pooling is silent exhaustion. If your pool is full and clients are queuing, queries slow down but do not always error immediately. Add monitoring:

// For PgBouncer: query the stats table
const stats = await adminPool.query(`
  SELECT database, cl_active, cl_waiting, sv_active, sv_idle, sv_used
  FROM pgbouncer.pools
`);
// cl_waiting > 0 means clients are queuing for a connection
// Alert on cl_waiting > 5 for more than 30 seconds

// For pg-pool: track pool events
pool.on("connect", () => metrics.increment("db.pool.connect"));
pool.on("acquire", () => metrics.gauge("db.pool.size", pool.totalCount));
pool.on("remove", () => metrics.decrement("db.pool.connect"));

Setting Pool Size

A common mistake is setting pool sizes too high. The optimal pool size at the Postgres level is often around (number of CPU cores * 2) + effective_spindle_count. For a 2-vCPU database, 10-20 real connections is often sufficient for high throughput. PgBouncer can then serve 1000+ clients against that pool.

At the application side (connections to PgBouncer or Hyperdrive), keep per-instance pool sizes low. In serverless, max: 1 or max: 2 per function instance is common, since the pooler handles the multiplexing.

Handling PGCONNECT_TIMEOUT

Network hiccups between your functions and the pooler cause hangs, not errors, by default. Always set connect timeout:

const pool = new Pool({
  connectionString: process.env.DATABASE_URL_POOLED,
  connectionTimeoutMillis: 3000,  // Fail fast on pool exhaustion
  idleTimeoutMillis: 30000,       // Release idle connections
  max: 2,                         // Per-instance limit
});

Decision Framework

Use Neon’s built-in pooler if: you are building a new project, you are comfortable with Neon as your Postgres provider, and you want zero operational overhead. The HTTP driver is particularly good for read-heavy APIs on any serverless platform.

Use Cloudflare Hyperdrive if: you are already running on Cloudflare Workers and you have a latency problem in addition to a connection problem. The edge co-location is the only solution here that actually reduces query latency, not just connection count.

Use self-hosted PgBouncer if: you run your own Postgres, you need to support multiple serverless platforms, or you need fine-grained control over pool configuration. RDS Proxy is PgBouncer-compatible and removes the operational overhead if you are already on AWS.

The one case where none of these fully applies is when you need LISTEN/NOTIFY, server-side prepared statements at scale, or advisory locks in a serverless context. These require session-level connections, which conflict with transaction-mode pooling. For those patterns, consider moving the stateful part of your workload to a long-running service rather than a serverless function.

The Underlying Trade-off

Every pooling solution works by sacrificing session state to gain connection sharing. Transaction-mode pooling means your serverless functions cannot rely on anything that lives outside of a transaction. This is actually a useful constraint: it pushes you toward stateless function design, which is what serverless was supposed to be in the first place.

The pooler you choose is mostly a deployment and latency question. The architectural constraint is the same across all three. Design your functions to be stateless within a transaction boundary, pick the pooler that fits your infrastructure, and the connection problem largely disappears.