PostgreSQL Access Control as a Map — Reasoning About Privileges Visually

Welcome to the first M-PUG session after the Summer break! Join us for an evening of practical AI and PostgreSQL discussion, community, and good company. We'll be gathering at the ground floor of Minc, and whether you're a longtime member or joining us for the first time, we’re excited to reconnect with the community and start the year with an insightful session.

Title: PostgreSQL Access Control as a Map — Reasoning About Privileges Visually

PostgreSQL access control is usually learned one feature at a time, a GRANT here, a policy there, default privileges somewhere else. That's exactly why it feels unpredictable: a change that looks isolated can have consequences several steps away, because these features were never actually isolated.

This talk takes a different angle. PostgreSQL stores its entire access control configuration as data, roles, memberships, privileges, ownership, and policies, all with relationships between them. Which means the whole thing can be drawn as a single ER diagram.

Once you can see that structure, commands like GRANT and REVOKE stop being incantations and become visible operations on the map — you can point to exactly what each one touches. We'll build that map up from scratch, then use it to walk through the cases that usually trip people up: why an isolated-looking change isn't, and how session context changes what your GRANTs actually mean.

You'll leave with one shared reference you can reason over, instead of a pile of features you memorize and hope you've connected correctly.

Covers: Config stored within the cluster. Does not cover pg_hba.conf, connection authentication, or encryption.

Audience: Full-stack and backend developers who know SQL and have been asked to touch PostgreSQL's access control.