Using Materialized Views for RLS in Supabase: Best Practices and UI Limitations

[vladimirzb]

Body

Hello everyone,

I'm working on a project where I need to calculate the final cost (gasto) for each expense by applying various taxes. I also need to implement Row-Level Security (RLS) to restrict data access based on the user ID.

Context:

• I have a table called gastos that stores individual expenses.
• I have another table called taxesValues that stores different types of taxes.
• A third table, gastosAppliedTaxes, establishes a many-to-many relationship between gastos and taxesValues, indicating which taxes are applied to each expense.
• I initially used a view called final_gastos to calculate the final cost (gasto) for each expense after applying the taxes. The view essentially joins gastos, taxesValues, and gastosAppliedTaxes to perform this calculation.

Why Materialized View?

I opted for a materialized view for two main reasons:

1. Performance: Materialized views store the result of the query, making data retrieval faster, especially when dealing with complex joins and calculations.

2. Row-Level Security (RLS): Unlike regular views, materialized views in PostgreSQL allow for the application of RLS policies. This is crucial for my application as I need to restrict data based on the user ID.

Questions:

1. Materialized Views for RLS:
   Given the above, I switched from using a view to a materialized view called final_gastos so that I can apply RLS. Is this a good approach? Are there any downsides or better alternatives?

2. Supabase UI Limitations:
   I noticed that the Supabase UI doesn't show policies for materialized views and lacks a UI for setting policies like it does for normal tables. Is this a limitation of Supabase, or am I missing something?

Any insights or recommendations would be greatly appreciated.

Thank you!

[GaryAustin1]

You can enforce RLS on regular views now with security_invoker. https://www.postgresql.org/docs/current/sql-createview.html
The UI is limited to displaying views and you need to use SQL to edit them.

[vladimirzb]

Thank you! I implemented this in my Supabase project recently and it has worked perfectly so far!

[benjaminpreiss]

I am wondering, though: If I create a view to "precalculate" a complex query to have it ready when needed, does RLS implicate that the view is recalculated upon each query? (Due to the fact that RLS on views is based on underlying tables)

That would undermine the idea of "precalculating" the query to have it ready upon request...

[stamler]

I'm fairly certain PostgreSQL as of v15 does NOT support RLS on materialized views, in contrast with regular views which do using security_invoker = true.