If your goal is to onboard nontechnical users quickly and not have to deal with them churning because they have to deal with thinking about those pesky "security rules" before they can get a working app, it totally makes sense that you would do this, especially if you just drop a get out of jail free "well, it's the end user's fault for not configuring their app securely" in your T&C

I believe it

The idea was that RLS (Row-level security) would be enabled on any tables exposed to the data API, and RLS was “heavily encouraged” to be turned on by default in the dashboard, and RLS was on by default since at least 2025. Tables require explicit RLS policies to be accessible by the data API, so by default it’s not open like that anymore.

In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.

Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.

I think the idea is to use edge functions against the database with RLS helping with low level access control, but it's still a tough design pattern to hold people accountable to. May as well as write the whole thing in a backend and just skip Supabase's API/RLS entirely.

The whole proposed benefit of their "query the database from the client" concept was the speed and ease of development. If you need edge functions (cost per invocation too, mind you) to make this happen, it's just a terrible design in general.

I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.

Have you looked at PocketBase? If I understand correctly it solves both of these to some degree and from my perspective pretty cleanly. Building a self-hosted, OS version of Firebase and SupaBase was the inspiration I believe.

https://pocketbase.io/

There is nothing wrong with this. It's no different from unauthenticated API routes to get public information. The issue is when somebody doesn't use RLS correctly.

>> The issue is when somebody doesn't use RLS correctly.

True, but I've seen staff+ level developers get bit by this. What hope do vibe coders have?

You have called out the issue precisely! The problem is that Supabase, and Lovable, market this product to people who are basically guaranteed to not know how to use RLS correctly. And that the defaults set assume that they do. So on one hand, you're saying "This product is for everyone!" Then on the other hand "You should have security expertise to use this app, and it's not our fault if you misconfigure it! Oh, by the way, we gave it to you misconfigured by default to make it easier for you, the end user, who is somehow both a rube and an expert who definitely understands how security works, to use the app, without configuring anything for security".