Nesta página, descrevemos o que é o pool de conexões gerenciadas e como usá-lo para otimizar
o gerenciamento de conexões de banco de dados para suas instâncias do Cloud SQL usando o pool.
O pool de conexões gerenciadas permite escalonar suas cargas de trabalho otimizando o uso de recursos
e a latência de conexão para suas instâncias do Cloud SQL usando o pool.
O pooling de conexões gerenciado atribui dinamicamente conexões de servidor a
solicitações recebidas quando possível. Isso oferece melhorias significativas de desempenho, especialmente para conexões escalonadas, ao absorver picos repentinos de conexão e reutilizar conexões de banco de dados atuais. Em vez de se conectar a um banco de dados específico, o Managed Connection Pooling se conecta a um cluster de poolers, que oferecem tempos de conexão mais curtos e escalonabilidade para suas cargas de trabalho. O número de poolers usados se baseia no número de núcleos de vCPU da instância.
Embora seja possível usar o pool de conexões gerenciado para qualquer carga de trabalho transacional, ele oferece o melhor benefício de capacidade e latência com aplicativos que contêm conexões de curta duração ou que resultam em um aumento repentino de conexões.
Para conexões de longa duração, o desempenho da conexão usando o
pooling de conexões gerenciadas pode ser um pouco menor do que ao usar uma conexão
direta. Nesse caso, o pooling de conexões gerenciado oferece escalonamento de conexões quando o número de conexões é muito alto. No entanto, para
aplicativos que normalmente estabelecem conexões de longa duração, é possível usar
conexões diretas com a instância.
Para usar o pool de conexões gerenciado, sua instância precisa atender aos seguintes requisitos:
Sua instância precisa ser da edição Cloud SQL Enterprise Plus.
Você precisa estar conectado à instância usando uma conexão direta ou
apenas o proxy de autenticação do Cloud SQL.
Você precisa estar conectado à instância usando um nome de usuário
e uma senha válidos. Usuários do IAM e de grupos do IAM não são compatíveis com o uso do pool de conexões gerenciadas.
O pooling de conexões gerenciado requer um número de versão de manutenção mínima de POSTGRES_$version.R20250302.00_04. Para mais
informações, consulte
Realizar manutenção de autoatendimento.
Portas usadas pelo pool de conexões gerenciadas para instâncias do Cloud SQL
Quando você ativa o pool de conexões gerenciadas, as portas usadas pelas instâncias do Cloud SQL para veicular o tráfego do banco de dados mudam. As portas usadas pelo pool de conexões gerenciadas são as seguintes:
Porta TCP 6432: usada para conexões diretas pelo pooler do Managed Connection Pooling. Para se conectar usando essa porta, especifique psql -p 6432 ao se conectar diretamente usando o cliente psql.
Porta TCP 3307: usada apenas para conexões do proxy de autenticação do Cloud SQL por um pooler de pool de conexões gerenciadas. Quando você usa o proxy de autenticação do Cloud SQL para se conectar ao pooler do Managed Connection Pooling, esse número de porta é configurado com o cliente do proxy de autenticação do Cloud SQL e não pode ser alterado.
Opções de configuração avançada
O pool de conexões gerenciado oferece as seguintes opções de pool que podem ser definidas usando o parâmetro pool_mode:
transaction (padrão): agrupa conexões no nível da transação.
max_pool_size: o tamanho máximo do pool de conexões. O valor padrão é 50 conexões.
min_pool_size: o tamanho do limite do pool de conexões. Se o número de conexões de servidor for menor que min_pool_size, adicione mais conexões ao pool. O valor padrão é 0 conexões.
max_client_connections: o número máximo de conexões permitidas
para sua instância. O valor padrão é de 5.000 conexões.
client_connection_idle_timeout: o tempo que uma conexão de cliente
permanece inativa antes de expirar. Esse valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é 0 segundos.
server_connection_idle_timeout: o tempo que uma conexão de servidor
permanece inativa antes de expirar. Esse valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é de 600 segundos.
query_wait_timeout: o tempo que uma consulta espera até expirar.
Esse valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é de 120 segundos.
max_prepared_statements: o número máximo de comandos de instruções preparadas nomeadas
no nível do protocolo compatíveis com o modo de pool de transações. O valor padrão é 0 declarações.
ignore_startup_parameters: os parâmetros que você quer ignorar e que não são rastreados nos pacotes de inicialização do Managed Connection Pooling por padrão.
server_lifetime: o tempo máximo que uma conexão de servidor fica sem uso
antes de o pool de conexões gerenciadas fechar. O valor padrão é de 3.600 segundos.
Limitações
Ao usar o pool de conexões gerenciadas com as instâncias do Cloud SQL Enterprise Plus, considere estas limitações:
Ativar o pool de conexões gerenciado em uma instância atual resulta
em uma reinicialização do banco de dados.
Quando você usa a API Cloud SQL para ativar, desativar ou configurar
o pool de conexões gerenciadas, a API instance.update não pode conter outras
atualizações de configuração de instância.
O pool de conexões gerenciado só pode ser usado com o proxy de autenticação do Cloud SQL versão 2.15.2 e mais recentes.
Se você estiver usando o conector de linguagem Go do Cloud SQL, recomendamos
uma versão mínima do Go de 1.24. Se você usa o Go versão 1.23 ou anterior, pode haver limitações de performance ao usar o pool de conexões gerenciadas.
Se você estiver usando o pool de conexões gerenciadas no modo de pool transaction, os seguintes recursos do SQL não serão compatíveis:
SET/RESET
LISTEN
WITH HOLD CURSOR
PREPARE/DEALLOCATE
PRESERVE/DELETE ROW tabelas temporárias
LOAD
Bloqueios consultivos no nível da sessão
Se você estiver usando a
biblioteca de interface de banco de dados asyncpg
para o pooler de pool de conexões gerenciadas nas portas 3307 e 6432, atualize o
max_prepared_statements para um valor maior que 0 e ative o suporte a
instruções preparadas no pooler de pool de conexões gerenciadas.
Se você estiver usando o Cloud SQL para PostgreSQL versão 17, a opção
sslnegotiation=direct não será compatível.
O rastreamento de IP do cliente não é compatível com o pool de conexões gerenciadas. Se você ativar a opção Armazenar endereços IP do cliente em Insights de consultas, os endereços IP do cliente vão aparecer como local em vez do endereço IP em si.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Managed Connection Pooling overview\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/managed-connection-pooling \"View this page for the MySQL database engine\") \\| PostgreSQL \\| SQL Server\n\n\u003cbr /\u003e\n\n|\n| **Preview\n| --- [Managed Connection Pooling](/sql/docs/postgres/managed-connection-pooling)**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| You can process personal data for this feature as outlined in the\n| [Cloud Data Processing\n| Addendum](/terms/data-processing-addendum), subject to the obligations and restrictions described in the agreement under\n| which you access Google Cloud.\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page describes what Managed Connection Pooling is and how to use it with your\nCloud SQL instances.\n\nManaged Connection Pooling lets you scale your workloads by optimizing resource utilization\nand connection latency for your Cloud SQL for PostgreSQL instances using pooling.\n\nManaged Connection Pooling dynamically assigns server connections to\nincoming requests when possible. This delivers significant performance\nimprovements, especially for scaled connections, by absorbing sudden\nconnection spikes and reusing existing database connections. Instead of\nconnecting to a particular database, Managed Connection Pooling connects to a\ncluster of poolers, which provide shorter connection times and scalability\nfor your workloads. The number of poolers used is based on the number of vCPU\ncores of your instance.\n\n\nWhile you can use Managed Connection Pooling for any transactional workloads,\nManaged Connection Pooling provides the most throughput and latency benefit with applications\nthat contain short-lived connections, or applications that result in a\nconnection surge.\n\nFor long-lived connections, the connection performance using\nManaged Connection Pooling can be slightly lower than when using a direct\nconnection. In this case, Managed Connection Pooling provides connection\nscaling when the number of connections is very high. However, for\napplications that typically establish long-lived connections, you might use\ndirect connections to your instance instead.\n\nFor more information on how to enable Managed Connection Pooling, see\n[Configure Managed Connection Pooling](/sql/docs/postgres/configure-mcp).\n\nRequirements\n------------\n\nTo use Managed Connection Pooling, your instance must meet the following requirements:\n\n- Your instance must be a Cloud SQL Enterprise Plus edition instance.\n- You must be connected to your instance using a direct connection, or the Cloud SQL Auth Proxy only.\n- 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.\n- Your instance must either be set up for [private service access](/sql/docs/postgres/private-ip#set_up_private_services_access_for_your_network), use public IP, or be a new instance with [Private Service Connect](/sql/docs/postgres/about-private-service-connect) enabled.\n- Your instance must use the new [Cloud SQL network architecture](/sql/docs/postgres/upgrade-cloud-sql-instance-new-network-architecture).\n- Managed Connection Pooling requires a minimum maintenance version number of `POSTGRES_$version.R20250302.00_04`. For more information, see [Perform self-service maintenance](/sql/docs/postgres/self-service-maintenance).\n\nPorts used by Managed Connection Pooling for Cloud SQL instances\n----------------------------------------------------------------\n\nWhen 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:\n\n- **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](/sql/docs/postgres/connect-admin-ip#connect).\n- **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](/sql/docs/postgres/connect-admin-ip#connect).\n- **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.\n\nAvailable configuration options\n-------------------------------\n\nManaged Connection Pooling offers the following pooling options that you can set using the `pool_mode` parameter:\n\n\u003cbr /\u003e\n\n- `transaction` (default): pools connections at a transaction level.\n- `session`: pools connections at a session level.\n\n| **Note:** The maximum number of server connections used by the pooler in Managed Connection Pooling is limited by the `max_connections` database configuration. Cloud SQL recommends adjusting this value based on your instance's workload requirements and the database instance size. For more information about the `max_connections` flag, see [Maximum concurrent connections](/sql/docs/quotas#maximum_concurrent_connections). To modify the `max_connections` database configuration flag for your instance, see [Configure database flags](/sql/docs/postgres/flags#config).\n\nYou can also\n[customize Managed Connection Pooling](/sql/docs/postgres/configure-mcp#modify-mcp)\nby using the following configuration parameters:\n\n- `max_pool_size`: the maximum size of the connection pool. The default value is 50 connections.\n- `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.\n- `max_client_connections`: the maximum number of connections allowed for your instance. The default value is 5,000 connections.\n- `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.\n- `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.\n- `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.\n- `max_prepared_statements`: the maximum number of protocol-level named prepared statements commands supported in transaction pooling mode. The default value is 0 statements.\n- `ignore_startup_parameters`: the parameters you want ignored, that aren't tracked in Managed Connection Pooling's startup packets by default.\n- `server_lifetime`: the maximum time a server connection is unused before Managed Connection Pooling closes it. The default value is 3600 seconds.\n\nLimitations\n-----------\n\nConsider the following limitations when using Managed Connection Pooling with\nyour Cloud SQL Enterprise Plus edition instances:\n\n- Enabling Managed Connection Pooling on an existing instance results in a database restart.\n- 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.\n- Managed Connection Pooling can only be used with Cloud SQL Auth Proxy version 2.15.2 and later.\n- 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.\n- If you're using Managed Connection Pooling in `transaction` pooling mode, then\n the following SQL features aren't supported:\n\n - `SET/RESET`\n - `LISTEN`\n - `WITH HOLD CURSOR`\n - `PREPARE/DEALLOCATE`\n - `PRESERVE/DELETE ROW` temp tables\n - `LOAD`\n - Session-level advisory locks\n- If you're using the\n [asyncpg database interface library](https://magicstack.github.io/asyncpg/current/)\n for Managed Connection Pooling pooler on port 3307 and 6432, then you must update the\n `max_prepared_statements` to a value larger than 0 to enable support for\n prepared statements in Managed Connection Pooling pooler.\n\n- If you're using Cloud SQL for PostgreSQL version 17, then the\n `sslnegotiation=direct` option isn't supported.\n\n- Client IP tracking isn't supported with Managed Connection Pooling. If you enable\n *store client IP addresses* in [query insights](/sql/docs/postgres/using-query-insights),\n then client IP addresses are displayed as `local` instead of the IP address\n itself.\n\nWhat's next\n-----------\n\n- [Create an instance](/sql/docs/postgres/create-instance)\n- [Configure Managed Connection Pooling](/sql/docs/postgres/configure-mcp)"]]