Just curious: my understanding is Hasura kind of discourages using RLS in lieu of their own access control layer[1]. Did you consider pros/cons of either approach?
People do use RLS for app user-level access control. It has been advocated by PostgREST for years [1] and also widely practiced by the PostGraphile community [2]. Hasura distinguishes itself by not actively advocating db-level access control. From what I recall, the first versions of Hasura were created at a time when Postgres' RLS was still very slow, but it's not clear to me why they still push their own solution. (Not saying there can't be a good reason for it, just not clear to me what it is, and I'd rather default to using functionality built into the database.)
But for column level permissions views are still needed, right? This isn't the case with hasura. (Of course hasura's approach has own limitations).
> Anyone accessing the generated API endpoint for the chat table will see exactly the rows they should, without our needing custom imperative server-side coding.
That looks like a bad joke. It is imperative, but now in the database. I'm not sure that it is better. Hasura's approach is declarative.
From my point of view, postgres' security model is still not suitable for users. It is more complex, imperative, and therefore more error prone. Hasura's approach is still not perfect, but a combination of postgres and hasura functionality make a huge difference.
[1] https://hasura.io/docs/latest/auth/authorization/basics/