Managed Connection Pooling overview

MySQL  |  PostgreSQL  |  SQL Server

Preview —Managed Connection Pooling

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. You can process personal data for this feature as outlined in theCloud Data Processing Addendum, subject to the obligations and restrictions described in the agreement under which you access Google Cloud. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

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

Managed Connection Pooling lets you scale your workloads by optimizing resource utilizationand connection latency for your Cloud SQL for PostgreSQL instances using pooling.Managed Connection Pooling dynamically assigns server connections toincoming requests when possible. This delivers significant performanceimprovements, especially for scaled connections, by absorbing suddenconnection spikes and reusing existing database connections. Instead ofconnecting to a particular database, Managed Connection Pooling connects to acluster of poolers, which provide shorter connection times and scalabilityfor your workloads. The number of poolers used is based on the number of vCPUcores 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 applicationsthat contain short-lived connections, or applications that result in aconnection surge.

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

For more information on how to enable Managed Connection Pooling, seeConfigure 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, orthe Cloud SQL Auth Proxy only.
  • You must be connected to your instance using a valid usernameand password. IAM and IAMgroup users aren't supported when using Managed Connection Pooling.
  • Your instance must either be set up forprivate service access,use public IP, or be a new instance withPrivate Service Connect enabled.
  • Your instance must use the newCloud SQL network architecture.
  • Managed Connection Pooling requires a minimum maintenance version number ofPOSTGRES_$version.R20250302.00_04. For more information, seePerform 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 whendirectly connecting using psql client.
  • TCP port 6432: used for direct connections by the PgBouncer server. To connect using this port, specifypsql -p 6432 whendirectly connecting using psql client.
  • TCP port 3307: used for the Cloud SQL Auth Proxy only connections by a PgBouncer server. When you use Cloud SQL Auth Proxy to connect to Pgbouncer, 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 setusing thepool_mode parameter:

  • transaction (default): pools connections at a transaction level.
  • session: pools connections at a session level.
Note: The maximum number of server connections used by the pooler inManaged Connection Pooling is limited by themax_connections database configuration.Cloud SQL recommends adjusting this value based on your instance'sworkload requirements and the database instance size. For more informationabout themax_connections flag, seeMaximum concurrent connections.To modify themax_connections database configuration flag for your instance,seeConfigure database flags.

You can alsocustomize Managed Connection Poolingby using the following configuration parameters:

  • max_pool_size: the maximum size of the connection pool. The defaultvalue is 50 connections.
  • min_pool_size: the threshold size of the connection pool. If the numberof server connections is less thanmin_pool_size, then add more serverconnections to the pool. The default value is 0 connections.
  • max_client_connections: the maximum number of connections allowedfor your instance. The default value is 5,000 connections.
  • client_connection_idle_timeout: the time that a client-connectionremains idle before it times out. This value can range from 0 to 2,147,483seconds, and the default value is 0 seconds.
  • server_connection_idle_timeout: the time that a server connectionremains idle before it times out. This value can range from 0 to 2,147,483seconds, 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 is120 seconds.
  • max_prepared_statements: the maximum number of protocol-level namedprepared statements commands supported in transaction pooling mode. The defaultvalue is 0.
  • ignore_startup_parameters: the parameters you want ignored, thataren't tracked in Managed Connection Pooling's startup packets by default.
  • server_lifetime: the maximum time a server connection is unusedbefore Managed Connection Pooling closes it. The default value is 3600 seconds.

Limitations

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

  • Enabling Managed Connection Pooling on an existing instance resultsin a database restart.
  • When you use the Cloud SQL API to enable, disable, or configureManaged Connection Pooling, theinstance.update API can't contain any otherinstance 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 recommenda minimum Go version of1.24. If you use Go version 1.23 or earlier, thenyou might experience limitations on performance when using Managed Connection Pooling.
  • If you're using Managed Connection Pooling intransaction pooling mode, thenthe 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 Cloud SQL for PostgreSQL version 17, then thesslnegotiation=direct option isn't supported.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-07-14 UTC.