Connecting an application

You could ship the proxy as a sidecar and have your application talk to localhost. It works. But there is a better answer for anything you control the source of: a language connector, which does the same job inside your process.

Google describes them as libraries that provide encryption and Identity and Access Management (IAM)-based authorization when connecting to a Cloud SQL instance (Cloud SQL docs). They exist for Java, Python, Go and Node.js, and they need no proxy binary.

The shape of the change

You are deleting configuration, not adding it:

Python, in full

pip install "cloud-sql-python-connector[pg8000]" sqlalchemy

import os
from google.cloud.sql.connector import Connector
import sqlalchemy

connector = Connector()

def getconn():
    return connector.connect(
        os.environ["INSTANCE_URI"],       # PROJECT_ID:REGION:INSTANCE
        "pg8000",
        user=os.environ["DB_USER"],       # app@PROJECT_ID.iam — no suffix
        db=os.environ["DB_NAME"],
        enable_iam_auth=True,             # the flag that removes the password
    )

engine = sqlalchemy.create_engine(
    "postgresql+pg8000://",
    creator=getconn,
    pool_size=5,
    max_overflow=2,
    pool_recycle=1800,                    # see "pooling", below
)

with engine.connect() as conn:
    print(conn.execute(sqlalchemy.text("SELECT current_user")).scalar())

Note the empty URL. SQLAlchemy is told the dialect and handed a creator; the connector supplies the socket. There is no host, no port and no password anywhere in the program.

The other three languages

Same three inputs, same flag, different spelling:

Not on that list? Use the proxy as a sidecar and connect to 127.0.0.1. It is a completely legitimate answer, and the only one for Ruby, PHP, Rust and .NET.

The three production details

Create the connector once

One Connector per process, at startup, kept for the life of the application. Constructing one per request creates a fresh TLS handshake and token fetch every time, and will fall over under load in a way that looks like the database is slow.

Pooling: the token is not the connection

An open connection is not invalidated when the token that opened it expires — PostgreSQL authenticates at connect time. The connector refreshes tokens so that new connections keep working. What this means in practice:

• Long-lived pooled connections are fine and stay fine.
• Set pool_recycle (or your pool's equivalent) to something under an hour anyway. It costs nothing and it means a connection that has gone quietly bad gets replaced.
• Let the connector own token refresh. Its default refresh strategy is built for long-running servers. Override it only for serverless runtimes, where background tasks are frozen between invocations — and then use the option the library documents for exactly that, not a timer of your own.

Egress, again

The connector has the same three destinations as the proxy: sqladmin.googleapis.com:443, oauth2.googleapis.com:443, and the instance on port 3307. A restrictive egress policy that allows 443 and 5432 produces a timeout that looks like a database outage.

Verify as the application, before you switch anything

The check that is worth the ten minutes: connect as the application's own identity, from where the application runs, and see what it can actually do. Not what the grants are believed to say.

SELECT current_user;             -- the service account, not yours
SELECT current_database();       -- the environment you meant
SELECT count(*) FROM some_table; -- reads work
INSERT INTO some_table …;        -- writes work
CREATE TABLE probe (i int);      -- should FAIL, see below

current_database() earns its place. A service reading the wrong environment's data connects successfully, runs successfully, and is wrong. There is no error to catch. Checking which database you are in is the only thing that finds it.

Check yourself