Security tab
The on-call surface. Four panels — lock graph, RLS inspector, role list, permission matrix — for the questions that come up when something is wedged.
Lock graph
Reads pg_locks joined with pg_stat_activityand renders the wait-for graph. Each node is a transaction; an edge means "waiting on." The cycle finder highlights deadlocks before Postgres' own deadlock detector kicks in.
txn 4821 (alice@app) ── waiting ──▶ txn 4810 (cron@batch) ── waiting ──▶ txn 4742 (admin@console) ── holds ──▶ orders.id_idx (RowExclusiveLock)RLS inspector
| Column | Source |
|---|---|
| Table | pg_tables filtered to user schemas. |
| RLS enabled? | pg_class.relrowsecurity. |
| Force RLS? | pg_class.relforcerowsecurity — important for table owners. |
| Policies | pg_policies — name, command, USING, WITH CHECK. |
| Roles affected | Computed by checking each role against the policy's role array. |
The "missing policies" column flags tables where RLS is enabled but no policy exists — those tables are effectively inaccessible to non-owner roles. A common cause of mysterious empty result sets in production.
Role list
-- The same data Studio renders, hand-queried:SELECT rolname, rolsuper, rolinherit, rolcreaterole, rolcreatedb, rolcanlogin, rolbypassrls, rolconnlimitFROM pg_rolesORDER BY rolname;Studio surfaces rolbypassrls in red — roles with BYPASSRLS see every row regardless of policy, which is rarely what you want for an application role.
Permission matrix
One row per role, one column per object kind (table, view, function, sequence). Cells show the granted privileges (SELECT, INSERT, UPDATE, DELETE, EXECUTE, USAGE). Click a cell to drill down to the specific object names.
role tables sequences functions─────────────────────────────────────────────────────────────────app_user SELECT, INSERT, UPDATE USAGE EXECUTE on 12read_replica SELECT USAGE EXECUTE on 4worker SELECT, INSERT, UPDATE USAGE, UPDATE EXECUTE on 8admin ALL ALL ALL