[andreadev]

RLS on Postgres is fine — I use it in production for tenant isolation and it works great. The problem is that Supabase puts it as the only thing standing between the public internet and your data. PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over. Behind a normal backend, a bad RLS policy is a defense-in-depth failure. In Supabase's model, it's a breach. That's a huge difference, and it gets worse when LLMs are writing the code because they'll happily scaffold a full app without ever thinking about access control.

[steve-chavez]

> PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over

Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.

> In Supabase's model, it's a breach.

Supabase is currently working on being closed by default.

[andreadev]

You're right, the GRANT layer is closed by default in PostgreSQL and PostgREST respects that. But in practice with Supabase, the very first thing you do is `GRANT ALL ON table TO authenticated` (and often `anon`) because nothing works through the client SDK without it. Every tutorial does this, every LLM-generated scaffold does this. At that point the first two layers are effectively gone and RLS is what's left. That's what I meant — not that PostgreSQL lacks defense in depth, but that Supabase's typical workflow collapses it down to one layer pretty quickly. Good to hear they're working on closed-by-default though. Kind of proves the point that the current model has been a problem in practice.