Laboratorio: mide y optimiza una política RLS

Resultado visible

Medirás una consulta con política RLS antes y después de añadir un índice y optimizar la condición. Seguridad y rendimiento conservarán la misma semántica.

Preparación

Usa datos sintéticos en un proyecto desechable. Crea suficientes filas para observar diferencias, dos usuarios y una columna user_id. Nunca copies datos de producción.

Estado y medida inicial

create policy "own rows"
on public.items for select
to authenticated
using (auth.uid() = user_id);

Guarda EXPLAIN (ANALYZE, BUFFERS) desde una sesión de prueba autorizada, tiempo, filas examinadas y filas devueltas. Una sola ejecución no es una conclusión: repite con el mismo conjunto.

Corrección guiada

create index if not exists items_user_id_idx
on public.items using btree (user_id);

drop policy "own rows" on public.items;
create policy "own rows"
on public.items for select
to authenticated
using ((select auth.uid()) = user_id);

Filtra también la consulta de la aplicación por user_id cuando corresponda. No cambies a una clave que evita RLS para mejorar tiempos.

Prompt para Codex

Compara planes antes/después y explica scan, índice, filas y coste sin
atribuir causalidad a una sola medida. Verifica con usuario A, usuario B
y anónimo que el conjunto autorizado no cambia. Añade una prueba de
aislamiento y un umbral de regresión razonable para este entorno.

Verificación y restauración

La consulta mejora o queda dentro del presupuesto y cada usuario conserva exactamente sus filas. Borra datos sintéticos. Mantén índice, policy y pruebas solo si el resultado está demostrado.

Fuentes oficiales

• Supabase: recomendaciones de rendimiento RLS
• PostgreSQL: EXPLAIN