[Question] Best Practice for RLS Key: Using auth.users.id vs supabase_id Column?
Hi Supabase community! 
I’m prototyping a large-scale application and evaluating the best schema design and RLS/RBAC patterns. I came across the official Supabase YouTube tutorial where they add a separate
Context & Goals:
- Implement a robust RBAC mechanism where roles (e.g. Admin, Editor, Viewer) control access across multiple schemas and tables.
- Enforce row-level security so users only see their own data, and roles can override this for administrative operations.
- Prototype quickly without introducing redundant columns or unnecessary joins.
What I’ve Tried:
- Following the tutorial’s pattern: adding
- Writing RLS policies that compare
- Considering directly using
Key Questions:
1. For prototyping a large application, is it better practice to keep a single
2. How would you structure RBAC roles and permissions at scale—would you extend RLS policies, use custom PostgreSQL functions, or integrate a dedicated roles table?
3. What database design patterns or diagrams do you recommend for quickly iterating on RBAC/RLS before productionizing?
Any insights, schema diagrams, or examples of prototyping strategies would be greatly appreciated!
Tags: #RBAC #RLS #Prototyping #SchemaDesign #Supabase
I’m prototyping a large-scale application and evaluating the best schema design and RLS/RBAC patterns. I came across the official Supabase YouTube tutorial where they add a separate
supabase_idusersauth.users.idContext & Goals:
- Implement a robust RBAC mechanism where roles (e.g. Admin, Editor, Viewer) control access across multiple schemas and tables.
- Enforce row-level security so users only see their own data, and roles can override this for administrative operations.
- Prototype quickly without introducing redundant columns or unnecessary joins.
What I’ve Tried:
- Following the tutorial’s pattern: adding
supabase_id UUIDpublic.usersDEFAULT auth.uid()- Writing RLS policies that compare
auth.uid()supabase_id- Considering directly using
id UUID PRIMARY KEY REFERENCES auth.users(id)public.usersKey Questions:
1. For prototyping a large application, is it better practice to keep a single
idpublic.usersauth.users.idsupabase_id2. How would you structure RBAC roles and permissions at scale—would you extend RLS policies, use custom PostgreSQL functions, or integrate a dedicated roles table?
3. What database design patterns or diagrams do you recommend for quickly iterating on RBAC/RLS before productionizing?
Any insights, schema diagrams, or examples of prototyping strategies would be greatly appreciated!
Tags: #RBAC #RLS #Prototyping #SchemaDesign #Supabase
