Don't use RLS in Supabase for your vibe-coded app

Don't use RLS in Supabase

RLS is a security nightmare that makes it easy to expose your database

RLS (Row-Level Security) is a database-level security feature for protecting data in a PostgreSQL database. It allows DB admins to set rules that limit which database rows users can view and edit.

RLS was popularised by Supabase as a way to access DB right from the client-side without implementing a traditional backend layer (this architecture was in turn inspired by Firebase). Supabase is one of the primary database providers that startup founders are choosing these days, so RLS got really popular.

Today RLS is a major reason why vibe-coded apps get exposed left and right leaking data and allowing public access to the database functions.

Even though RLS is proven to be a dangerous practice to be used as a primary auth mechanism, it’s getting used even more now as it's pushed by vibe-coding tool Lovable which became very popular. Lovable itself was exposed through RLS vulnerabilities multiple times (most recent April 20, 2026 ).

The Downsides of RLS

It’s much easier to say when RLS makes sense, rather than list all the downsides. But to convince you a bit, here’s just a few points on why RLS is bad:

The auth and business logic is spread between app and database

RLS allows skipping explicit filtering conditions in SQL and teaching bad SQL habits. Even the official Supabase guides tell you not to do that

RLS can be misconfigured after incorrect updates, suddenly exposing the DB and showing non-authorised data for your app users

RLS often are not tracked under git and changed manually instead of proper migrations

RLS query overhead slows down queries and introduces a different way to write optimised queries

Database rules are harder to test than application code

RLS syntax is repetitive and can lead to infinite recursion for common data structures like social network

When RLS does make sense:

If you’re building a multi-tenant app (separate databases for different clients) and want to enforce an additional mechanism for in-depth protection, not a primary way to protect data

The alternative: how to protect your data without RLS

It’s simple: create and host a backend layer that does proper auth checks. This is a default proven architecture used by majority of startups and enterprises.

Turn off Supabase Data API and never do requests to your database directly from your client app. Access your data with service key from the backend side and don’t use public key (except for Auth and Realtime).

You can still use Supabase Auth and enjoy dashboard, you can still create built-in supabase edge functions if you don’t want to host your own backend.

You’re using coding agents anyway for your app, there’s no reason to avoid traditional secure architecture and risk your business being exposed.

Using Lovable Cloud? Migrate from it to your custom Supabase account. Lovable Cloud is a lock-in and ticking bomb that will expose your data sooner or later. Learn more

Consider Convex as a solid Backend-as-a-Service AI-native provider that avoided RLS by design.

We generally don't recommend relying on RLS. It shifts security logic into the database, where policy misconfiguration, silent failures, and connection pooling interactions are difficult to debug

— PlanetScale, Approaches to tenancy in Postgres

Expressing your entire authorization model with RLS is not for the faint of heart

— Neon, Is Postgres RLS for Everything and Everyone?

RLS is bad architecture. there's a reason convex doesn't do it

— Jamie Turner, Convex CEO tweet

People using RLS need to pick up a book on APIs.

— Abhinav Asthana, Postman CEO tweet

Explore the full stack

100+ modern dev tools and platforms for building startups, reviewed and compared.

Browse Stack

Ship faster than
your competition

Focus on customers and sales while we handle product delivery. Hire a dedicated AI maker or a whole product team.

Launch new products

Fix your delivery

Hit fundraising milestones

View recent work

[Analytics Chart]

Wireframe v0.1

Sarah Chen CEO, Founder

$127k

MRR

2,847

Customers

+23%

Growth

Sales Performance

Latest Deal

Enterprise plan closed

Acme Corp · $12k/mo

Full-stack development

Build a custom-coded web/mobile SaaS

Integrate AI

Use OpenAI and other AI APIs to build your SaaS

UI/UX design

Design the product MVP before building

Release regularly

Keep your customers engaged with regular fixes and updates