When establishing a connection, PostgreSQL spawns a separate backend process for each client. For a large number of clients, this model can cause high consumption of system resources and lead to significant performance degradation, especially on multicore systems. The reason is high contention for PostgreSQL resources between backends. Besides, the size of many PostgreSQL internal data structures is proportional to both the complexity of algorithms for these structures and the number of active backends.

Most production Postgres Pro installations reduce the number of spawned backends using external tools, such as J2EE, odyssey, or pgbouncer, one of the most popular connection poolers for Postgres Pro. However, external connection poolers require additional efforts for installation, configuration, and maintenance. If the pooler is single-threaded, like pgbouncer, you also have to launch multiple pooler instances as it can otherwise cause a bottleneck on high-load systems.

To address these challenges, Postgres Pro Enterprise provides an experimental built-in connection pooler. Unlike external solutions, it does not require any additional maintenance and does not introduce any limitations for clients. With built-in connection pooling enabled, clients can continue using session configuration parameters, prepared statements, and temporary tables as if there is no proxy.

The chapters that follow describe built-in connection pooler architecture and provide configuration instructions.