It only has access disabled if you enable RLS on that table. If you do `CREATE TABLE`, or don't check the checkbox in the UI (TBF it's big and green and has a warning that's hard to miss), then access is public.
I guess my main concern is that it's hard to setup RLS correctly using SQL. Because it's two separate statements, if your `CREATE TABLE` succeeds, but the `CREATE POLICY` does not, you're also exposed. And it is more annoying than it should've been to test the rules (Firebase has a dedicated tool for that).
I now just use Supabase to host a normal Postgres that only my backend connects to. That works well.
I built a supabase app the past two days, and I agree.
I did find it a footgun that creating a table through SQL was not private by default. (Why doesn't Supabase apply RLS by default to tables created through SQL?)
Serverless also turned out to be more trouble than it was worth. In particular:
* Doing DB business logic in JS is gross.
* It's tricky to secure a table to be semi-public. e.g. you have a bookmark site and you don't want users to browse all URLs, just the ones they have bookmarked. The best solution appears to be disabling foreign-keys until transactions are done and then having a complicated policy.
* It's a pain to set up a CLI client that interacts with the DB. I think you have to copy-paste the access AND refresh tokens to it. I couldn't figure out a way to create my own API tokens.
A backend is nice, because it is private by default.
It's front-and-center constantly, and has _all_ access disabled by default on tables every time I use it.