This can simplify your data-access layers quite a lot and pushes you towards better security practices like limiting the scope of permissions granted to your applications' role.
If you like Polar but can't use it for whatever reason it does a lot of what Polar does.
[0] https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html
Is this something that is done in practice for web applications? Like in my Django app, create a Postgresql role for every user in my auth_user table?
The most common way is to create a role though, yeah. I find that creating a role is not a downside, since it is generally just a row in a table that postgresql's permission system also uses.
See the local option here for more options: https://www.postgresql.org/docs/current/functions-admin.html...
If using the role-mapping feature of postgrest it works similarly, only setting the ROLE instead of the variables.
In general it moves computation closer to the data and in aggregate that generally offsets most increases in query times.
If you design your schemas carefully the performance cost is easy to swallow. As always analyze your queries under different table sizes and see what works for you.
The benefit is that your application code doesn't have to use any complex RBAC->SQL compilation. You can just 'select foo, bar, baz from mytable;` and RLS will take care of making sure your application servers never see the data that the user doesn't have access to.