76 RLS policies rewritten in one migration: the auth.uid() init-plan trap in Supabase
A recent migration revealed that 76 RLS policies in Supabase were inefficiently using the auth.uid() function. This function was being called for each row, leading to performance issues as the data size increased. By wrapping the function in a subquery, the performance was significantly improved, allowing the function to be evaluated only once per query.
- ▪Supabase's RLS policies were found to be inefficient due to the repeated calls of auth.uid() for each row.
- ▪The issue was identified by Supabase's auth_rls_initplan advisor during a pre-deployment check.
- ▪By modifying the policies to wrap auth.uid() in a subquery, the performance improved as the function was evaluated only once per query.
Opening excerpt (first ~120 words) tap to expand
try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3896990) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Vadym Arnaut Posted on May 20 76 RLS policies rewritten in one migration: the auth.uid() init-plan trap in Supabase #supabase #postgres #performance #webdev TL;DR. If your Supabase RLS policies call auth.uid() directly inside USING(...) or WITH CHECK(...), Postgres re-evaluates the function once per row. Wrap it as (SELECT auth.uid()) and the planner hoists the call to a single init plan that runs once per query. Same logical query, different plan, different cost at scale.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at DEV.to (Top).
Discussion
0 commentsMore from DEV.to (Top)
