Row-Level Security (RLS)
Row-Level Security (RLS) is a PostgreSQL feature that lets you attach policies to a table so each database role can only see or modify the rows it is allowed to. In Supabase it is the primary mechanism that stops one signed-in user from reading another user's data through the auto-generated API.
Also known as: RLS · Postgres row-level security
RLS is opt-in: a table has no row restrictions until you both ENABLE row-level security on it and add policies. A table with RLS disabled is fully readable and writable by anyone holding the anon key, because Supabase exposes every table over its REST and Realtime APIs by default.
Policies are written as SQL USING (for reads) and WITH CHECK (for writes) expressions, typically keyed on auth.uid() to compare the row's owner column against the authenticated user.
In a Lovable app this matters because Lovable provisions a Supabase backend and exposes your tables over its auto-generated API — RLS is what stands between a signed-in user and everyone else's rows. Common mistake: enabling RLS on a table but forgetting to add a policy, which silently blocks all access and makes the feature look broken; the opposite mistake — never enabling it — leaves the table wide open to anyone with the anon key.
Related
Stuck on the thing this term describes? Talk to a senior engineer.
Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.