Yes you're right. Supabase uses PostgREST behind the scenes. You can read about how the roles work here: https://postgrest.org/en/stable/auth.html https://postg

Yes you're right. Supabase uses PostgREST behind the scenes. You can read about how the roles work here: https://postgrest.org/en/stable/auth.html https://postgrest.org/en/stable/auth.html Basically, you have a role which is an "authenticator" - this is the one you connect to in the database with. This has basically no privileges except to "change into" a new role. When an API route is called, PostgREST checks the headers to see if there is a JWT then gets the "role" out of the JWT. This JWT maps to a PostgreSQL role, which will have slightly higher privileges. Inside the JWT is the User ID too - so you can use this inside your RLS policies. So in summary: > 1. Avoid having a postgres user for each application user, and You only need 2 roles - an "autheticator" role, and an "authenticated" role > 2. Ensure that the right user is passed to RLS. It's encoded int he JWT. > I guess a similar approach would work with Postgraphile, Definitely. Postgraphile works with RLS and JWT too, so it should be achievable