The whole premise of RLS is that you only have to think about data permissions in one place.

If you're up for maintaining that, and if you're willing to suffer the serious performance hits it inevitably entails, it can be a very convenient and secure option.

The problem is that most engineers (let alone vibe coders) are decidedly terrible at db design. The outcome here is entirely predictable.

Agreed. Nothing inherently bad about RLS itself, but the way it was pushed forward in the Supabase model was always bound to be dangerous. Because like you say, it requires proper DB design, whereas the selling points of the Supabase model are simplicity and speed, so there's a bit of a mismatch here.

> The whole premise of RLS is that you only have to think about data permissions in one place.

I’ve always preferred treating RLS as one layer of defense in depth, or an underlying safety net for when your backend code forgets to filter properly. Like wearing underwear just in case you get holes in your pants. I don’t think that’s Supabase’s philosophy though and that’s always bothered me.

RLS can be a dangerous point for secure implementations. Even if you use single tenant you might need to filter for departmental or individual permissions and you're often a single missed join from sharing data you shouldn't. In the past year or so I've adopted the strategy DBs that only contain the data the audience is allowed to see using DuckDB - specifically for scenarios where the end users can write their own queries (a growing approach with AI), so there's nothing to leak. You still need to be careful with security but it's analogous of pushing a runtime bug to compile time. Most people don't really have big data; small data for the win!