You are running a mission-critical application on a Cloud SQL for PostgreSQL database with a multi- zonal setup. The primary and read replica instances are in the same region but in different zones. You need to ensure that you split the application load between both instances. What should you do?

PgBouncer is a lightweight connection pooler specifically designed for PostgreSQL. In a scenario with a primary instance and one or more read replicas, the application is responsible for directing write traffic to the primary and read traffic to the replicas. PgBouncer facilitates this by managing pools of database connections. You can configure separate pools in PgBouncer for the primary and the read replica. The application then connects to the appropriate pool, and PgBouncer routes the connection to the correct database instance. This approach efficiently manages connections and enables the application to split the read/write load as required.

A. Cloud Load Balancing (specifically Internal TCP/UDP Load Balancing) is not application-aware. It cannot distinguish between read and write SQL queries to route traffic to the correct instance (primary vs. replica).
C. HTTP(S) Load Balancing is a Layer 7 load balancer designed for web traffic (HTTP/HTTPS). It is incompatible with the PostgreSQL wire protocol and cannot be used for database connections.
D. The Cloud SQL Auth proxy provides secure, encrypted, and authorized connections to Cloud SQL instances. Its primary function is security and connectivity, not load balancing or read/write splitting.

1. Using a connection pooler: Google Cloud's documentation on managing database connections recommends using a connection pooler like PgBouncer to handle connection management efficiently, which is essential for load splitting.

Source: Google Cloud Documentation, "Manage database connections", Section: "Connection pooling".

Reference: "For PostgreSQL, we recommend using PgBouncer..."

2. Application responsibility for routing: The documentation for Cloud SQL read replicas explicitly states that the application logic is responsible for directing traffic to the appropriate instance. A tool like PgBouncer is used to implement this logic.

Source: Google Cloud Documentation, "Replication in Cloud SQL", Section: "Read replicas".

Reference: "Your application connects to a read replica the same way it connects to a primary instance. Your application must be configured to send write requests to the primary instance and read requests to the read replica."

3. Cloud SQL Auth Proxy purpose: The official documentation clarifies that the proxy's role is secure connectivity, not load distribution.

Source: Google Cloud Documentation, "About the Cloud SQL Auth proxy".

Reference: "The Cloud SQL Auth proxy is a Cloud SQL connector that provides secure access to your instances without a need for Authorized networks or for configuring SSL."

4. Cloud Load Balancing limitations: The documentation for Internal TCP/UDP Load Balancing shows it distributes TCP connections but lacks the application-layer intelligence to inspect SQL queries for read/write splitting.

Source: Google Cloud Documentation, "Internal TCP/UDP Load Balancing overview".

Reference: "Internal TCP/UDP Load Balancing is a regional load balancer that enables you to run and scale your services behind an internal IP address... The load balancer distributes traffic to backends..." This describes network-level, not application-level, balancing.