I don't know how so many people bought into the row-level security stuff with the frontend talking directly to the Supabase backend. Always seemed like a minefield to me. I've used Supabase a time or two but always as a standard Postgres that I'd connect to from my backend. They will send you a million emails though about how your DB is insecure because you don't have RLS configured.
In this case we're talking about vibe coders, who don't know about the implementation details. But we've gotten here in the first place because a lot of developers adopted this Supabase RLS serverless model. I always found it surprising that this model stuck.
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!
In this case we're talking about vibe coders, who don't know about the implementation details. But we've gotten here in the first place because a lot of developers adopted this Supabase RLS serverless model. I always found it surprising that this model stuck.
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.
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.