Is Postgres RLS for Everything and Everyone?
In Neon, we recommend using a project-per-user pattern for multitenancy whenever possible. If this doesn’t work for you and you’re placing all your tenants within a single Postgres database, you should at least use RLS to prevent cross-tenant access—but expressing your entire authorization model with RLS is not for the faint of heart. In this blog post, we uncover why.
With the recent launch of Neon Authorize, I’ve been building a lot of things with Postgres RLS, as well as talking to a lot of people who use it for their apps. And one question that keeps coming up is: should all of the authorization for my app be expressed with RLS? Should I even use RLS?
I’ll start by saying that RLS is not the best authorization model out there. First of all, the syntax itself is very dense and repetitive. For example, if you’re building a todo list, this is the SQL you’ll have to write to properly protect your todos table:
But RLS has other issues! For example, if you are trying to check whether a user belongs to a given organization in order to let them access or manage a specific resource, you will likely bump into “infinite recursion detected in policy”. We learned this the hard way while working on the RLS implementation for a social network. There’s a couple of different ways around it:
