Managed Connection Pooling overview

This page describes what Managed Connection Pooling is and how to use it with your Cloud SQL instances.

Managed Connection Pooling lets you scale your workloads by optimizing resource utilization and connection latency for your Cloud SQL for PostgreSQL instances using pooling. Managed Connection Pooling dynamically assigns server connections to incoming requests when possible. This delivers significant performance improvements, especially for scaled connections, by absorbing sudden connection spikes and reusing existing database connections. Instead of connecting to a particular database, Managed Connection Pooling connects to a cluster of poolers, which provide shorter connection times and scalability for your workloads. The number of poolers used is based on the number of vCPU cores of your instance.

While you can use Managed Connection Pooling for any transactional workloads, Managed Connection Pooling provides the most throughput and latency benefit with applications that contain short-lived connections, or applications that result in a connection surge.

For long-lived connections, the connection performance using Managed Connection Pooling can be slightly lower than when using a direct connection. In this case, Managed Connection Pooling provides connection scaling when the number of connections is very high. However, for applications that typically establish long-lived connections, you might use direct connections to your instance instead.

For more information on how to enable Managed Connection Pooling, see Configure Managed Connection Pooling.

Requirements

To use Managed Connection Pooling, your instance must meet the following requirements:

  • Your instance must be a Cloud SQL Enterprise Plus edition instance.
  • You must be connected to your instance using a direct connection, or the Cloud SQL Auth Proxy only.
  • You must be connected to your instance using a valid username and password. IAM and IAM group users aren't supported when using Managed Connection Pooling.
  • Your instance must either be set up for private service access, use public IP, or be a new instance with Private Service Connect enabled.
  • Your instance must use the new Cloud SQL network architecture.
  • Managed Connection Pooling requires a minimum maintenance version number of POSTGRES_$version.R20250302.00_04. For more information, see Perform self-service maintenance.

Ports used by Managed Connection Pooling for Cloud SQL instances

When you enable Managed Connection Pooling, the ports used by Cloud SQL instances to serve database traffic change. The ports used by Managed Connection Pooling are as follows:

  • TCP port 5432: used for direct connections by the Postgres database server. This is the default port number used when directly connecting using psql client.
  • TCP port 6432: used for direct connections by the Managed Connection Pooling pooler. To connect using this port, specify psql -p 6432 when directly connecting using psql client.
  • TCP port 3307: used for the Cloud SQL Auth Proxy only connections by a Managed Connection Pooling pooler. When you use Cloud SQL Auth Proxy to connect to Managed Connection Pooling pooler, this port number is configured with the Cloud SQL Auth Proxy client and can't be changed.

Available configuration options

Managed Connection Pooling offers the following pooling options that you can set using the pool_mode parameter:

  • transaction (default): pools connections at a transaction level.
  • session: pools connections at a session level.

You can also customize Managed Connection Pooling by using the following configuration parameters:

  • max_pool_size: the maximum size of the connection pool. The default value is 50 connections.
  • min_pool_size: the threshold size of the connection pool. If the number of server connections is less than min_pool_size, then add more server connections to the pool. The default value is 0 connections.
  • max_client_connections: the maximum number of connections allowed for your instance. The default value is 5,000 connections.
  • client_connection_idle_timeout: the time that a client-connection remains idle before it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 0 seconds.
  • server_connection_idle_timeout: the time that a server connection remains idle before it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 600 seconds.
  • query_wait_timeout: the time that a query waits until it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 120 seconds.
  • max_prepared_statements: the maximum number of protocol-level named prepared statements commands supported in transaction pooling mode. The default value is 0 statements.
  • ignore_startup_parameters: the parameters you want ignored, that aren't tracked in Managed Connection Pooling's startup packets by default.
  • server_lifetime: the maximum time a server connection is unused before Managed Connection Pooling closes it. The default value is 3600 seconds.

Limitations

Consider the following limitations when using Managed Connection Pooling with your Cloud SQL Enterprise Plus edition instances:

  • Enabling Managed Connection Pooling on an existing instance results in a database restart.
  • When you use the Cloud SQL API to enable, disable, or configure Managed Connection Pooling, the instance.update API can't contain any other instance configuration updates.
  • Managed Connection Pooling can only be used with Cloud SQL Auth Proxy version 2.15.2 and later.
  • If you're using the Cloud SQL Go Language Connector, then we recommend a minimum Go version of 1.24. If you use Go version 1.23 or earlier, then you might experience limitations on performance when using Managed Connection Pooling.

  • If you're using Managed Connection Pooling in transaction pooling mode, then the following SQL features aren't supported:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW temp tables
    • LOAD
    • Session-level advisory locks

  • If you're using the asyncpg database interface library for Managed Connection Pooling pooler on port 3307 and 6432, then you must update the max_prepared_statements to a value larger than 0 to enable support for prepared statements in Managed Connection Pooling pooler.

  • If you're using Cloud SQL for PostgreSQL version 17, then the sslnegotiation=direct option isn't supported.

  • Client IP tracking isn't supported with Managed Connection Pooling. If you enable store client IP addresses in query insights, then client IP addresses are displayed as local instead of the IP address itself.

What's next