Managed Connection Pooling overview

Managed Connection Pooling lets you scale your workloads by optimizing resource use and connection latency for your Cloud SQL instances. Managed Connection Pooling creates a pool of threads to handle incoming requests. This provides significant performance improvements, especially for scaled connections, by absorbing sudden connection spikes without overloading the server with a growth in the number of threads.

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.
  • Managed Connection Pooling requires a minimum maintenance version number of MYSQL_$version.R20250531.01_10. For more information about performing self-service maintenance, see Perform self-service maintenance.

Advanced configuration options

You can customize Managed Connection Pooling by modifying the max_pool_size configuration option.

The max_pool_size option controls the amount of concurrency for Managed Connection Pooling. The default value depends on the number of vCPU cores in your instance's machine configuration.

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 Managed Connection Pooling is enabled for your instance, the value of the thread_cache_size metric is defaulted to 0.

Thread pooling versus connection multiplexing

In Cloud SQL for MySQL, Managed Connection Pooling uses a server-side thread pool rather than an external connection multiplexer:

  • Thread pooling (Managed Connection Pooling): clients connect directly to the database server, which reuses a bounded pool of worker threads (max_pool_size) to execute queries across active sessions instead of creating a dedicated thread per connection. This reduces CPU and memory overhead during high concurrency, but each open client connection still maintains a dedicated server session and counts toward the max_connections limit.
  • Connection multiplexing (such as ProxySQL): clients connect through an intermediary proxy that shares a smaller pool of backend database connections across many client connections. This directly reduces the total number of open server-side connections.

If your workload requires reducing the number of server-side connections to avoid reaching the max_connections limit, then use an external connection pooler such as ProxySQL. Alternatively, you can increase the max_connections flag based on your instance's memory capacity.

What's next