zanith

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.

TXT
txn 4821 (alice@app) waiting txn 4810 (cron@batch)
waiting txn 4742 (admin@console)
holds orders.id_idx (RowExclusiveLock)

RLS inspector

ColumnSource
Tablepg_tables filtered to user schemas.
RLS enabled?pg_class.relrowsecurity.
Force RLS?pg_class.relforcerowsecurity — important for table owners.
Policiespg_policies — name, command, USING, WITH CHECK.
Roles affectedComputed 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

SQL
-- The same data Studio renders, hand-queried:
SELECT
rolname,
rolsuper, rolinherit, rolcreaterole, rolcreatedb,
rolcanlogin, rolbypassrls, rolconnlimit
FROM pg_roles
ORDER 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.

TXT
role tables sequences functions
app_user SELECT, INSERT, UPDATE USAGE EXECUTE on 12
read_replica SELECT USAGE EXECUTE on 4
worker SELECT, INSERT, UPDATE USAGE, UPDATE EXECUTE on 8
admin ALL ALL ALL