Hey, I wanted to check about Column Level Security - maybe you have some thoughts: in Firebase it's not possible to restrict what fields to return in a document unless you build a cloud function or something like that. What about Supabase? RLS looks great but the same issue I guess - how to restrict what columns can be returned? Only by building middleware or there are some other ways?

AFAIK, there are 2 standard ways to achieve this: 1) Hide your table in a non-public schema (i.e. a schema which is NOT exposed to the world via PostgREST) and then expose it to the world via a view in the public schema, where the view only exposes the relevant fields 2) Use PostgreSQL privilege system to revoke SELECT/UPDATE permission on certain columns of the table Both approaches are described in more details here: https://www.enterprisedb.com/postgres-tutorials/how-implement-column-and-row-level-security-postgresql There is also a relevant discussion on Supabase's repo about this: https://github.com/supabase/supabase/discussions/3158

wow thanks @User! So if I understood it correctly in suggestion 1 - it will be limited to all users as the view will be public - what if more granular permissions are required (multi-role - where each role has access to a different set of columns?). In this light with suggestion 2 in Supabase we have only a 2 roles - anon and authenticated so we can't really extend beyond that. Or am I missing something?

Indeed, a scenario where you have different user roles that need access to different columns is a bit more complicated, but it seems that you already discovered the 2 other approaches which can help with that - functions and views with an additional clause which serves as a RLS in order to return empty data for users that are NOT supposed to use that particular view (similar to what is suggested here: https://stackoverflow.com/a/64283814/2606261)