Database Connection Pooling: PgBouncer, PgCat, and Supavisor Compared
PostgreSQL forks a new process for each connection. At 500+ connections, memory usage and context switching kill performance. Connection poolers solve this by multiplexing thousands of application connections over a handful of database connections.
Why Pooling Matters More Than Ever
Serverless functions create a new database connection per invocation. A Lambda function at 1000 concurrent executions means 1000 connections. PostgreSQL's default max_connections is 100. Without pooling, your database dies under serverless workloads.
PgBouncer: The Battle-Tested Default
Single-threaded, lightweight, and reliable. Transaction-mode pooling lets thousands of clients share 50 database connections. The downside: no multi-host support, no built-in load balancing.
PgCat: The Modern Alternative
Multi-threaded, written in Rust, supports query load balancing across replicas, automatic failover, and sharding. Better performance than PgBouncer under high concurrency, but newer and less battle-tested.
Supavisor: Built for Serverless
Supabase's Elixir-based pooler handles millions of connections with tenant isolation. Native support for named prepared statements in transaction mode — something PgBouncer cannot do. Best for multi-tenant serverless applications.