RLS Enabled but No Policies = Silent Lockout in Production

Supabase RLS has a non-obvious default behavior: **when RLS is enabled on a table but no policies exist, all API access is denied**. Zero rows are returned. No error is thrown. The table appears empty to anyone accessing it through the anon or authenticated key. This becomes a trap during development. When you create tables through the Supabase Table Editor, RLS is enabled automatically. When AI tools create tables via raw SQL, RLS is **not** enabled by default. Developers who check “RLS enabled” in the dashboard may still have tables with zero policies — meaning their app silently shows empty screens to users. **The three-part check before any production launch:** 1. **RLS enabled?** Go to Authentication → Policies. Every table storing user data should show the “RLS enabled” badge. 2. **At least one policy per operation?** A table with RLS enabled but no SELECT policy returns nothing. A table with no INSERT policy rejects all writes. 3. **Policies use `auth.uid()`, not `auth.role()`?** See Fix 001. Additionally, SQL-created tables bypass the dashboard’s default RLS setting. The community-documented pattern: AI code generators (Lovable, Cursor, Bolt) typically create tables via SQL, so assume RLS is off until verified. ## Why it matters Developers see the app working fine in their own session (they may be using the service role key locally) while real users see blank pages. This is one of the most common launch-day disasters in AI-built apps. ## Suggested next action Before your next deployment, go to Supabase → Authentication → Policies and confirm every table has both an enabled RLS badge and at least one policy for each operation you use.

RLS Enabled but No Policies = Silent Lockout in Production

Sources

Confidence check

Evidence

Discussion