Back to blog

PostgreSQL Connection Pooling: PgBouncer vs Neon Serverless vs Native Connection Pool

Unlike databases like MySQL or MongoDB, which handle connections using lightweight threads, PostgreSQL utilizes a process-per-connection model.

Every time a client opens a connection, PostgreSQL forks a new physical operating system process on the database server.

This architecture ensures stability, but forks are expensive. Each process consumes several megabytes of RAM and CPU cycles. If you have hundreds of client instances or serverless functions querying the database simultaneously, your database server will quickly run out of memory and slow down.

To scale PostgreSQL, you must implement Connection Pooling.

In this guide, we will analyze why PostgreSQL forks are expensive, compare PgBouncer against serverless pools, and configure transaction-level pooling.

The Cost of PostgreSQL Connections

Because PostgreSQL forks a system process for each connection, opening and closing connections rapidly introduces performance issues:

  • Resource Bloat: Each fork consumes 2MB to 10MB of RAM. 500 connections can consume up to 5GB of memory just maintaining idle state.
  • Latency Overhead: The TCP handshake and process fork add dozens of milliseconds of latency before a query even begins executing.
  • CPU Contention: With hundreds of active processes, the OS spends more time context-switching between CPU tasks than executing queries.

To solve this, connection pooling keeps a set of active connections open to the database and shares them among client requests.

1. Application-Level Pools (Native pg-pool)

For traditional long-running applications (such as an Express server or Django API running on a virtual machine), you use an application-level pool inside your code.

import { Pool } from 'pg';

// Create a pool of 20 database connections
const pool = new Pool({
  host: 'db.example.com',
  database: 'main',
  user: 'admin',
  max: 20, // Max connections in pool
  idleTimeoutMillis: 30000, // Close idle connections after 30s
});

export async function query(text: string, params: any[]) {
  // Pulls a connection from the pool, runs query, and returns connection back to pool
  return pool.query(text, params);
}
  • Pros: Zero extra infrastructure to manage; fast query speeds.
  • Cons: Only works inside a single application process. If you scale your API to 20 containers, each running a pool of 20 connections, you open 400 connections to the database. In serverless environments (like AWS Lambda or Vercel Functions), where instances boot and die instantly, application pools fail completely.

2. PgBouncer: The Dedicated Caching Proxy

PgBouncer is a lightweight, external connection pool manager for PostgreSQL. It sits between your application and the database server, presenting itself as a standard PG database.

Your applications connect to PgBouncer, and PgBouncer routes the queries through a optimized pool of physical connections leading to PostgreSQL.

PgBouncer operates in three modes:

  • Session Pooling (Conservative): PgBouncer allocates a database connection to the client for the entire duration of the client's session (until the client disconnects).
  • Transaction Pooling (Recommended): PgBouncer allocates a database connection to the client only for the duration of a single database transaction. Once the transaction completes, the connection returns to the pool, allowing other clients to reuse it. This allows 1,000 clients to share 20 physical database connections.
  • Statement Pooling (Aggressive): PgBouncer allocates connections for individual SQL queries. Multi-statement transactions are not supported in this mode.

Basic PgBouncer Configuration (pgbouncer.ini)

[databases]
# Forward connections to the physical PG database
main_db = host=127.0.0.1 port=5432 dbname=prod

[pgbouncer]
listen_port = 6432
listen_addr = *
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

# Configure pool limits
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

3. Serverless Pools: Neon Serverless Driver

If you host applications on Serverless hosting platforms (like Vercel, Netlify, or Cloudflare Workers), setting up PgBouncer infrastructure is complex.

Modern serverless PostgreSQL providers (such as Neon) provide specialized Serverless Drivers. These drivers tunnel database queries over WebSockets or HTTP request pipelines, routing queries through integrated connection gateways automatically.

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

export async function onRequest() {
  // Routes the query over a WebSocket connection to Neon's connection pool gateway
  const sql = neon(process.env.DATABASE_URL!);
  const posts = await sql`SELECT * FROM posts LIMIT 10`;
  return new Response(JSON.stringify(posts));
}

Conclusion

Scaling PostgreSQL requires separating client instances from physical database processes. For single monolith applications, native application-level pools are sufficient. If you run containerized APIs (like Kubernetes or Docker clusters), deploying PgBouncer in transaction mode manages connection overheads. For serverless deployments, utilize WebSocket-based serverless drivers to bypass connection limitations.