# Row-level security (RLS)

**Source:** https://promtable.com/glossary/row-level-security

> Row-level security is a Postgres feature where access policies are enforced per-row at the database layer — Supabase's primary auth pattern, foundational for multi-tenant apps that talk to Postgres directly from the client.

---
Row-level security is a Postgres feature where access policies are enforced per-row at the database layer — Supabase's primary auth pattern, foundational for multi-tenant apps that talk to Postgres directly from the client.

Traditional web apps put authorization in the app layer: the API server checks the user, then queries the database. Row-level security flips that: the database itself enforces 'user can see / modify only their own rows' via SQL policies. This unlocks client-direct database access (Supabase's flagship pattern) — the JS client hits Postgres directly, JWT in the request, RLS policies validate each row. By 2026 RLS is the standard for serverless / Jamstack apps using Postgres. Failure modes: missing policies expose data ([[supabase-rls-needs-real-auth]] is a common bug), overly permissive policies grant cross-tenant access, performance issues when policies require subqueries on every row.

## When to use

- Multi-tenant SaaS on Postgres / Supabase.
- Client-direct database access patterns.

## Common mistakes

- Forgetting to ENABLE RLS on a table — all rows exposed by default.
- Using `auth.uid()` without a real authenticated session — policy denies everything silently.

## Related terms

- [serverless-database](https://promtable.com/glossary/serverless-database)
- [edge-function](https://promtable.com/glossary/edge-function)

*Last updated: 2026-06-01*
---

Original page: https://promtable.com/glossary/row-level-security
Maintained by Promtable (https://promtable.com). Content: CC BY 4.0. Cite as "Promtable — https://promtable.com/glossary/row-level-security".
Contact: info@vibecodingturkey.com.