A course for developers

Postgres on Google Cloud

Connect to a managed PostgreSQL database with no password anywhere — from your laptop and from your code — and know which of three layers broke when it breaks.

Eight lessons · about two and a half hours · free · no Google Cloud experience assumed

Managed PostgreSQL on Google Cloud does not work the way you expect. There is no hostname to connect to, no password to put in a .env file, and no firewall rule listing who may connect. The first time you meet it, that feels like obstruction.

It is not. Access is granted to an identity rather than to a secret or a network position, and once that clicks, the whole design reads as straightforward — including the error messages, which are unusually informative if you know what they are pointing at.

This course is what one team learned getting there, including the three mistakes that only surfaced because someone ran a verification query nobody had thought to run.

Lessons

• 01 The ground floor Projects, principals, roles and Application Default Credentials. The four Google Cloud ideas the rest of this depends on, and nothing more.
• 02 Why there is no database password What password-plus-allowlist actually costs, and what replaces it. Why a leaked connection string here is not an incident.
• 03 Your first connection hands on Two tools, two commands, a psql prompt. Then the four ways it fails — including the one that wastes an afternoon because it looks like the database is down.
• 04 Three layers that must all be true core Project IAM, the IAM database user, and PostgreSQL grants are independent gates that fail at different moments. The single most useful thing in the course.
• 05 Connecting an application hands on Swap host, port and password for a language connector. Working Python, the other three languages, and the pooling mistakes that only appear under load.
• 06 Giving a workload an identity Attached service accounts, workload identity federation, impersonation, and keys as the last resort — with the six rules that make a key survivable if you truly need one.
• 07 Designing the role layer deepest Three PostgreSQL behaviours that defeat a perfectly correct Google Cloud setup: owners hold DDL unconditionally, roles are cluster-wide, and grants are snapshots.
• 08 Private IP and the VPC Taking the public IP away: private services access, the allocated range you can never resize, and the developer access you must replace before you switch it off.

Reference

The compressed version. Written to be printed and kept next to you, not read once.

• → Connection cheat sheet Every command, port, username form and client setting on one page.
• → Failure modes Every error message, the layer it belongs to, and the fix — including the four that work but are wrong.
• → Role pattern A runnable, idempotent PostgreSQL bootstrap, ending in the verification that proves the boundary is real.
• → Glossary The vocabulary, with the aliases this course deliberately avoids.

If you only have twenty minutes

Read lesson 4 and print the failure modes sheet. Between them they resolve most of what goes wrong. Come back for the rest when something surprises you.

What this course is not

It does not cover creating an instance, sizing it, high availability, backups, or migrating data into it. It starts from an instance that exists and someone has given you access to. It also assumes Cloud SQL for PostgreSQL; AlloyDB's connector works on the same principles, with different role and product names.

Where to ask

The error strings in this subject are specific enough that searching the literal text usually works. When it does not:

• Stack Overflow, google-cloud-sql — where the exact messages live.
• cloud-sql-proxy issues — Google engineers answer directly, and this is the right venue for behaviour the documentation does not describe.
• r/googlecloud — for "is this the normal way to do X" questions.
• pgsql-general — lesson 7's questions are PostgreSQL questions, not Google ones, and are better asked here.