Why RLS Approval Still Causes Postgres 'Permission Denied' and How to Fix It

A developer building a coffee shop stored-value system encountered a persistent 'permission denied for table users' error in PostgreSQL, despite having a valid Row-Level Security (RLS) policy that explicitly allowed admin access. The root cause turned out to be a two-gate permissions model: GRANT controls table and column access, while RLS only governs which rows are accessible — and the developer had been debugging the wrong gate. Because the admin RPC function was set to SECURITY INVOKER, it ran under the authenticated role, which had never been granted write access to sensitive columns like balance and tier fields. The fix was to create a SECURITY DEFINER wrapper function that runs as the database owner, with an is_admin() guard placed as the very first statement to prevent privilege escalation. This pattern allows only verified admins to write privileged columns, while keeping those columns fully locked down from ordinary authenticated users.