Improving RLS and query performance

We implemented RLS optimizations in Chapter 6 and learned that an RLS policy that selects data from another table will trigger the additional RLS policies on that table, and so on and so forth. We’ve also drastically reduced RLS complexity by checking for the tenant access directly with auth.jwt() and app_metadata instead of doing multiple sub-queries. However, there are a few more things that can come in handy to improve RLS performance, which we’ll look at now.

Note

Before we go into RLS optimization specifics, I’d like to define the term stable (as in “stable query,” “stable function”, or “stable expression”). In Postgres, stable refers to something that is guaranteed to have no side effects and to return the same result for the same arguments for each row. It’s basically the equivalent of the concept of pure functions within a programming context (https://en.wikipedia...