Mastering Cloud SQL Connectivity: Pooling, Proxies, and Performance for PostgreSQL | by Andrew Feldman | Google Cloud – Community | Apr, 2025

Migrating to a managed database service like Google Cloud SQL for PostgreSQL unlocks tremendous benefits: reduced operational overhead, enhanced scalability, and robust security features. However, navigating the nuances of database connectivity in the cloud is crucial for realizing these advantages fully. Whether you’re migrating an existing application or building a new cloud-native service, getting connectivity right is paramount for performance, security, and reliability.

This post dives into the essential strategies and best practices for connecting your applications to Cloud SQL for PostgreSQL, covering network paths, authentication, connection pooling (including the new Managed Connection Pooling feature), and troubleshooting common pitfalls.

The first fundamental decision is how your application will reach your Cloud SQL instance. You have two primary network paths:

1. Public IP: Your instance gets an external IPv4 address, making it reachable over the public internet. While seemingly straightforward, this path requires careful security considerations. Access must be explicitly granted, either by whitelisting specific source IP addresses in “Authorized Networks” or, preferably, by using the Cloud SQL Auth Proxy for IAM-based authorization. Exposing a database publicly increases its attack surface, so if you use Authorized Networks, ensure your IP lists are strict and consider enforcing SSL/TLS encryption for data in transit. Public IP is often necessary for external clients or some PaaS services connecting via the Auth Proxy.(2)
2. Private IP: Your instance is only accessible via internal RFC 1918 IP addresses within your Virtual Private Cloud (VPC) network or peered networks.2 This is achieved through Private Services Access, which connects your VPC to the Google-managed network hosting your Cloud SQL instance.5 Private IP significantly reduces the attack surface and is the strongly recommended approach for applications running within Google Cloud (like Compute Engine, GKE, Cloud Run, etc.). It generally offers lower latency and relies on VPC firewall rules for network-level access control. While the initial network setup (allocating IP ranges, enabling Private Services Access) is more involved, the security benefits for internal applications are substantial.(5)

Key Takeaway: Prioritize Private IP for internal Google Cloud resources. Use Public IP only when necessary, always coupled with strong authorization (preferably the Auth Proxy) and encryption.(2)

Regardless of whether you use Public or Private IP, the Cloud SQL Auth Proxy is Google Cloud’s recommended method for secure connections.3 Think of it as a secure sidecar or local client that handles the complexities of authentication and encryption for you.

How it Works:

• Your application connects to the Auth Proxy running locally (e.g., on 127.0.0.1 or a Unix socket).(3)
• The proxy uses the IAM credentials of the user or service account running it to authenticate with the Cloud SQL Admin API.3 The principal needs the Cloud SQL Client role (or equivalent permissions like cloudsql.instances.connect).
• It obtains short-lived SSL certificates and establishes a secure TLS 1.3 tunnel directly to your Cloud SQL instance over the existing network path (Public or Private IP).
• It forwards traffic between your application and the database through this encrypted tunnel.

Benefits:

• Robust Security: Leverages strong IAM authentication and automatic TLS 1.3 encryption.(3)
• Simplified Management: Eliminates the need to manage SSL certificates manually or maintain IP whitelists.(3)
• IAM Database Authentication (Optional): Can integrate directly with Cloud SQL’s IAM database authentication feature.(9)

Key Takeaway: Use the Cloud SQL Auth Proxy whenever possible. It simplifies secure connectivity and centralizes authorization through IAM.3 Ensure the service account running the proxy has the correct IAM permissions and that the Cloud SQL Admin API is enabled.3

Establishing database connections is expensive.1 Doing it for every request slows down your application and can quickly hit the max_connections limit on your Cloud SQL instance, leading to errors like FATAL: sorry, too many clients already.15 Connection pooling is essential for managing database resources efficiently.

Pooling Strategies:

1. Application-Level Pooling: Libraries within your application code (e.g., HikariCP for Java, pgxpool for Go) manage a pool of connections.19 This can be simple for monolithic applications but becomes problematic in distributed systems. Each application instance maintains its own pool, potentially leading to a massive total connection count across all instances.(19)
2. Server-Side Pooling (Self-Managed PgBouncer): An external, lightweight pooler like PgBouncer acts as an intermediary.(13) Multiple application clients connect to PgBouncer, which maintains a smaller, controlled pool of connections to the actual PostgreSQL database. This is highly recommended for microservices or scaled applications, as it centralizes connection management and dramatically reduces the load on the database. However, it requires deploying, managing, and configuring PgBouncer yourself.
3. Cloud SQL Managed Connection Pooling (Preview): Google Cloud now offers a built-in, managed connection pooling solution directly within Cloud SQL for PostgreSQL.(29)

Deep Dive: Managed Connection Pooling (Preview)

This new feature aims to provide the benefits of connection pooling without the overhead of managing a separate service like PgBouncer.

• How it Works: Instead of connecting directly to the database process, connections are routed to a cluster of managed poolers. These poolers dynamically assign server connections to incoming requests, optimizing reuse and reducing latency, especially for workloads with short-lived connections or sudden surges.
• Benefits: Simplified setup compared to self-managed PgBouncer, potential for significant throughput and latency improvements, better absorption of connection spikes.
• Current Status & Limitations (Important!): Managed Connection Pooling is currently in Preview. This means it’s subject to specific terms, might have limited support, and could change. Key limitations during Preview include:
• Requires Cloud SQL Enterprise Plus edition.
• Requires connection via direct connection or the Cloud SQL Auth Proxy (version 2.15.2+).
• Does not support IAM database users.
• Requires specific network configurations (Private Services Access, Public IP, or PSC) and the new Cloud SQL network architecture.
• Enabling it restarts the database instance.
• Certain SQL features (like session-level advisory locks or LISTEN) are unsupported in transaction pooling mode.(29)
• Configuration: It offers transaction (default) and session pooling modes, similar to PgBouncer, along with various tuning parameters (max_pool_size, timeouts, etc.).
• Integration: It works seamlessly with the Cloud SQL Auth Proxy, providing both secure connectivity (via the proxy) and efficient connection management (via the managed pooler).

Choosing Your Pooling Strategy:

• Simple/Monolithic App: Application-level pooling might suffice if carefully tuned.
• Distributed/Scaled Apps:
• Consider the new Managed Connection Pooling (Preview) if you meet the requirements (Enterprise Plus, etc.) and are comfortable with Preview features. It offers a potentially simpler, integrated solution.
• Otherwise, self-managed PgBouncer remains a robust and widely used option for centralized control, especially if you need features not yet in the managed offering or don’t meet the Preview requirements.
• Pooling Mode (PgBouncer or Managed): Choose Transaction mode for maximum efficiency if your application doesn’t rely on state across transactions. Use Session mode if it does.

Key Takeaway: Always use connection pooling. Evaluate Managed Connection Pooling (Preview) if applicable; otherwise, PgBouncer is a strong choice for scaled applications. Select the pooling mode carefully. Avoid double pooling (using both application-level and server-side).(19)

It’s common to see discrepancies between the number of connections shown in Cloud SQL monitoring (like the num_backends metric) and the limits configured in your pooler (e.g., PgBouncer’s max_client_conn or Managed Pooling’s max_client_connections).(16) Why?

• Idle Connections: Poolers keep connections open even when idle, ready for reuse. These idle connections are counted by Cloud SQL monitoring (num_backends) as active server processes. A large pool size (pool_size or max_pool_size) can lead to high monitored counts even with low application activity.29
• Internal Processes: PostgreSQL uses connections for its own background tasks (autovacuum, replication, etc.), which are included in the monitored count.(7)
• Direct Connections: Some tools or scripts might bypass the pooler, connecting directly.
• Metric Definitions: Cloud Monitoring tracks server-side backends, while pooler limits might refer to client-side connections or the server-side pool target. They measure different things.

Key Takeaway: Don’t expect monitored connection counts (num_backends) to perfectly match client-side pooler limits. Focus on ensuring num_backends stays comfortably below your instance’s max_connections limit, considering idle connections and internal processes. Use pg_stat_activity on the database and pooler-specific stats (like PgBouncer’s SHOW POOLS; or Managed Pooling metrics when available) for a detailed view.

When connections fail, a systematic approach helps:

1. Authentication/Authorization:

• FATAL: password authentication failed: Check database username/password.
• Auth Proxy NOT_AUTHORIZED: Verify the proxy’s service account IAM permissions (Cloud SQL Client role), check credential source, ensure Cloud SQL Admin API is enabled.
• Public IP Refused: Check Authorized Networks list.
• Managed Pooling & IAM: Remember IAM users are not supported with Managed Pooling (Preview).

1. Network Issues:

• Timeouts/Refused: Check firewalls (client, VPC, Cloud Firewall), routing, DNS. Use telnet or nc to test port reachability. Verify VPC Peering/PSC if using Private IP/Managed Pooling. Use GCP Connectivity Tests.29 Check TCP keepalives for idle connection drops.(15)

1. Proxy/Pooler Problems:

• Cannot connect locally (Auth Proxy/PgBouncer): Ensure proxy/pooler process is running, check its logs for errors, verify its configuration (instance name, listen ports). Check for pool exhaustion.
• Managed Pooling Issues: Check configuration parameters, ensure Preview limitations are met (instance type, network, versions).

1. Resource Exhaustion:

• FATAL: sorry, too many clients already: Tune pooler (pool_size/max_pool_size), consider scaling instance (max_connections increases with memory).
• General Slowness/Timeouts: Check instance CPU/RAM/Disk I/O in Cloud Monitoring. Optimize queries or scale instance.

1. Application Logic:

• Connection Leaks: Ensure application code reliably closes connections (e.g., try-with-resources, finally blocks).
• Lack of Retries: Implement exponential backoff for transient errors.
• Managed Pooling & Transaction Mode: Ensure application doesn’t use unsupported SQL features if using transaction mode.

Key Takeaway: Debug layer by layer: Application -> Pooler (Managed or Self-Managed) -> Proxy -> Network -> Cloud SQL Instance. Use logs (Application, Proxy, Cloud SQL), pg_stat_activity, and Cloud Monitoring as essential tools.

• Prioritize Private IP/PSC: Use secure, internal network paths whenever possible.(29)
• Embrace the Auth Proxy: Make it your default for secure, IAM-managed connections, especially when using Managed Pooling.
• Implement Smart Pooling: Evaluate Managed Connection Pooling (Preview) if suitable; otherwise, use PgBouncer. Tune the mode and size carefully.
• Monitor Actively: Track num_backends, resource utilization, and latency. Set up alerts.(1)
• Code Defensively: Ensure proper connection closing and implement retry logic. Be mindful of pooling mode limitations.

By thoughtfully configuring your network path, leveraging the Cloud SQL Auth Proxy, and implementing robust connection pooling (whether managed or self-managed), you can build reliable, secure, and performant applications on Cloud SQL for PostgreSQL.

1. General best practices | Cloud SQL for PostgreSQL | Google Cloud, https://cloud.google.com/sql/docs/postgres/best-practices
2. About connection options | Cloud SQL for PostgreSQL | Google Cloud, https://cloud.google.com/sql/docs/postgres/connect-overview
3. About the Cloud SQL Auth Proxy | Cloud SQL for PostgreSQL — Google Cloud, https://cloud.google.com/sql/docs/postgres/sql-proxy
4. Cloud SQL for PostgreSQL documentation — Google Cloud, https://cloud.google.com/sql/docs/postgres
5. Learn about using private IP | Cloud SQL for PostgreSQL | Google …, https://cloud.google.com/sql/docs/postgres/private-ip
6. Cloud Run -> SQL: Private or Public IP? : r/googlecloud — Reddit, https://www.reddit.com/r/googlecloud/comments/1gy8o9r/cloud_run_sql_private_or_public_ip/
7. Debug connection issues | Cloud SQL for PostgreSQL | Google Cloud, https://cloud.google.com/sql/docs/postgres/debugging-connectivity
8. Connect using the Cloud SQL Auth Proxy | Cloud SQL for …, https://cloud.google.com/sql/docs/postgres/connect-auth-proxy
9. GoogleCloudPlatform/cloud-sql-proxy: A utility for connecting securely to your Cloud SQL instances — GitHub, https://github.com/GoogleCloudPlatform/cloud-sql-proxy
10. Help Connecting to Cloud SQL Database : r/googlecloud — Reddit, https://www.reddit.com/r/googlecloud/comments/1iprn12/help_connecting_to_cloud_sql_database/
11. PostgreSQL database secure connection using Cloud SQL Auth proxy — Unravel Data, https://docs.unraveldata.com/en/gcp-create-psql-cloud-proxy.html
12. Connect to Cloud SQL (PostgreSQL) instance with Sequelize, https://www.googlecloudcommunity.com/gc/Databases/Connect-to-Cloud-SQL-PostgreSQL-instance-with-Sequelize/td-p/712416
13. Architecting a Scalable and Secure Cloud-Based Database Solution: A Deep Dive into Integrating Cloud SQL, PgBouncer, CloudSQL Proxy, and HammerDB for Optimal Performance — Medium, https://medium.com/google-cloud/architecting-a-scalable-and-secure-cloud-based-database-solution-a-deep-dive-into-integrating-a22a5771aeaa
14. Securing Cloud SQL Connectivity: A Deep Dive into the Cloud SQL Auth Proxy — Bomberbot, https://www.bomberbot.com/proxy/securing-cloud-sql-connectivity-a-deep-dive-into-the-cloud-sql-auth-proxy/
15. Troubleshoot | Cloud SQL for PostgreSQL, https://cloud.google.com/sql/docs/postgres/troubleshooting
16. Re: Intermittent DB connections of CloudSQL on pos… — Google …, https://www.googlecloudcommunity.com/gc/Databases/Intermittent-DB-connections-of-CloudSQL-on-postgres/m-p/840867
17. Google Cloud SQL connection limit is not the same as in the documentation — Stack Overflow, https://stackoverflow.com/questions/48151531/google-cloud-sql-connection-limit-is-not-the-same-as-in-the-documentation
18. Quotas and limits | Cloud SQL for PostgreSQL | Google Cloud, https://cloud.google.com/sql/docs/postgres/quotas
19. PostgreSQL: Database Layer Pooling v/s Application Layer pooling — DBA Stack Exchange, https://dba.stackexchange.com/questions/337745/postgresql-database-layer-pooling-v-s-application-layer-pooling
20. PgBouncer vs application side pooler : r/PostgreSQL — Reddit, https://www.reddit.com/r/PostgreSQL/comments/p9vwun/pgbouncer_vs_application_side_pooler/
21. PgBouncer vs. Pgpool-II: Choosing the Right Tool for Your PostgreSQL Environment, https://horkan.com/2025/01/01/pgbouncer-vs-pgpool-ii-choosing-the-right-tool-for-your-postgresql-environment
22. postgresql — What are advantages of using transaction pooling with …, https://stackoverflow.com/questions/12189162/what-are-advantages-of-using-transaction-pooling-with-pgbouncer
23. Setting Up a PostgreSQL Database Using GCP Cloud SQL | by Durga Gadiraju — Medium, https://medium.com/itversity/setting-up-a-postgresql-database-using-gcp-cloud-sql-76e9da6823b1
24. Google Cloud SQL — OpsRamp Documentation, https://docs.opsramp.com/integrations/public-cloud/google-cloud/supported-services/google-cloud-sql-int/
25. Cloud SQL Postgre connection problem with credenti, https://www.googlecloudcommunity.com/gc/Databases/Cloud-SQL-Postgre-connection-problem-with-credentials/m-p/759908
26. Re: Cloud SQL Proxy — randomly loosing connection due to being “NOT_AUTHORIZED”, https://www.googlecloudcommunity.com/gc/Databases/Cloud-SQL-Proxy-randomly-loosing-connection-due-to-being-quot/m-p/632592
27. Connect to a CloudSQL instance via CloudSQL Auth Proxy | by Fabricio Pedroso Jorge, https://fabriciojorge.medium.com/connect-to-a-cloudsql-instance-via-cloudsql-auth-proxy-1b7ac3ba1761
28. Issues connecting Data Fusion to CloudSQL Postgres instance — getting a 403 “The client is not authorized to make this request” — Server Fault, https://serverfault.com/questions/1147792/issues-connecting-data-fusion-to-cloudsql-postgres-instance-getting-a-403-the
29. Managed Connection Pooling overview | Cloud SQL for PostgreSQL, https://cloud.google.com/sql/docs/postgres/managed-connection-pooling