Managed Connection Pooling overview

This page describes what Managed Connection Pooling is and how to use it to optimize database connection management for your Cloud SQL instances using pooling.

Managed Connection Pooling lets you scale your workloads by optimizing resource use and connection latency for your Cloud SQL instances using pooling. Managed Connection Pooling dynamically assigns server connections to incoming requests when possible. This provides 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.

Each pool is associated with a unique database and user. Once a client is authenticated, the pool attempts to reuse one of the idle server connections within the pool to connect the database to the server. If a server connection isn't available, then it creates a new server connection in the pool to connect the database. 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, it provides the most throughput and latency benefit to 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 want to avoid using connection pooling.

You can use Identity and Access Management to secure connections, depending on the port. For more information on how IAM works in Cloud SQL and its restrictions, see IAM authentication.

For more information about enabling 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 only a direct connection or the Cloud SQL Auth Proxy.
  • Your instance must 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.R20250727.00_14. For more information about performing self-service maintenance, 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. You can use Identity and Access Management to secure connections, depending on the port.

The ports used by Managed Connection Pooling and their available IAM options are as follows:

Pooling options

Managed Connection Pooling lets you manage how connections are pooled using the pool_mode parameter. You can use the following pooling options:

  • transaction (default): pools connections at a transaction level. Connections are returned to the pool after each transaction completes. Cloud SQL recommends using transaction pooling mode for short-lived connections.
  • session: pools connections at a session level. Each session uses a dedicated server connection that maintains a session state. This reduces pooling efficiency. When a client disconnects, the server returns to the connection pool.

Advanced configuration options

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

Configuration name Description
max_pool_size The maximum number of server connections allowed to a database and user pair in each connection pool. The default value is 50 connections.
min_pool_size The minimum number of server connections available at any time in each connection pool.

If the number of server connections is less than the min_pool_size, then this setting adds more server connections to the pool. This helps manage sudden increases in database load after periods of inacitivty and ensures connections are available and ready to use.

The default value is 0 connections.
max_client_connections The maximum number of connections allowed for your instance when using Managed Connection Pooling. The default value is 5,000 connections.
max_prepared_statements The maximum number of protocol-level named prepared statements supported in transaction pooling mode.

Setting this option to 0 disables prepared statement support. For optimal performance, this value should exceed the number of commonly used prepared in your database. A high number of prepared statements in Managed Connection Pooling cmay cause an increase in memory usage.

The default value is 0 statements.
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 for a server connection in a pool before it times out.

Setting this option to 0 disables it, which allows indefinite client queuing. Enabling this option prevents unresponsive servers from holding up connections.

This value can range from 0 to 2,147,483 seconds, and the default value is 120 seconds.
ignore_startup_parameters The parameters you want ignored, that aren't tracked in the Managed Connection Pooling startup packets by default.
server_lifetime The maximum time a server connection is unused before Managed Connection Pooling closes it. If the value is set to 0 seconds, then the connection is immediately closed after use.

The default value is 3600 seconds.

Limitations

When using Managed Connection Pooling with your Cloud SQL Enterprise Plus edition instances, consider these limitations:

  • 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.

  • If your instance is using Cloud SQL Auth Proxy and has Managed Connection Pooling enabled, then manual IAM database authentication isn't supported. You can only use automatic IAM authentication.

Server connections used by Managed Connection Pooling

The max_connections database configuration limits the maximum number of server connections a pooler in Managed Connection Pooling can use. Cloud SQL recommends adjusting this value based on your instance's workload requirements and the database instance size. During peak load, the number of connections for authentication can become very high.

If you're using the default max_pool_size of 50 pools on your instance, then we recommend reserving at least 15 server connections per CPU for Managed Connection Pooling when you set the max_connections flag for your database. For more information about the max_connections flag, see Maximum concurrent connections. To modify the max_connections flag for your instance, see Configure database flags.

What's next