The Acme playground - pgroles docs

The playground is the core Acme course sandbox: durable ownership, capability roles, defaults, the nested analyst hierarchy with its delegated administration, Priya’s reassigned legacy objects, and the security-review function. There is no scripted finish. Choose a role, change the query, and follow the evidence.

Final lab · Core Acme sandbox

PostgreSQL 18.3 · PGlite ↗

Explore the core Acme database

The canonical roles, ownership, grants, defaults, hierarchy, and security-review function are open. Choose a role and query freely; the tenant logins and RLS policies live in their separate disposable lab.

Final lab · Core Acme sandbox

PG 18.3

Step 1 of 1

Every Run starts from this step’s prepared database. Changes from previous runs are discarded.

Step 1

Find every path to orders

Start with evidence, not assumptions. Change the role or query freely; every run gets a fresh copy of Acme’s core sandbox.

Which roles can read orders, call the definer function, administer a membership, or own an object?

Run as

SELECT
  session_user,
  current_user,
  has_schema_privilege(current_user, 'app', 'USAGE') AS schema_usage,
  has_table_privilege(current_user, 'app.orders', 'SELECT') AS orders_select,
  pg_has_role(current_user, 'orders_reader', 'USAGE') AS through_reader;

Editable SQL · disposable browser database · changes are discarded after the run

PostgreSQL output

PostgreSQL’s rows, command tags, or exact error will appear here.

Keep investigating.

How the browser lab models roles

The selector sets session authorization inside an isolated PGlite database. Statements run one at a time and autocommit, like psql: execution stops at the first error, and earlier statements keep their effect. PostgreSQL performs ordinary role, ownership, schema, and object checks; the diagram comes from catalog privilege queries after your SQL. This is not a password, CONNECT, pg_hba.conf, or concurrent-session test.

A practical audit loop

Name the exact operation and starting role.
Run the operation instead of inferring it from one catalog row.
Trace every surviving path: membership, schema and object ACLs, ownership, PUBLIC, functions, and delegation.
Compare PostgreSQL with the desired pgroles graph.
Review the plan, apply it, and repeat the operation as a positive or negative test.

The grants, memberships, default privileges, and limitations pages are the exhaustive reference. This course stays focused on the operational story that makes those mechanisms worth remembering.

The playground runs real PostgreSQL interactions in your browser. It intentionally does not seed the separate tenant RLS scenario; use Same table, different rows for that lesson. The explorer complements this sandbox by simulating an ordered pgroles plan from a snapshot you prepare and scrub; it does not replace live checks.