It really sucks that Supabase is what LLMs default to. Supabase has an innate problem.
- RLS asks for way more discipline to use securely than the bog-standard "client+API+SQL db"
- Supabase has spent all of its marketing budget on beginners (pre-LLMs) and completely non-technical users (post-LLMs)
This combination is always going to lead to complete trainwrecks. It's like marketing angle grinders to people who have never learnt to use a saw.
The chance of Supabase ever changing from RLS-first to RLS-last is near zero as well as it's too core to their brand. As long as it's RLS-first it doesn't matter how many "barriers" and "checks" they put up either. They will never put up enough to slow adoption, which is what would be needed.
It would be much better for everyone if the standard vibe coding stack was based on, for example, Cloudflare. Pages/Workers/D1 or something. Not that I'm a fan of CF (and there may be better alternatives) but at least it would cut these cases of "entire DB exposed" at least in half.
Another bit of irony is that the whole selling point of Supabase has been "time from zero to one", "less code/boilerplate required", "I'm a frontend developer and don't want to learn backend". But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
> But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
This is precisely the approach we are taking for Specific (https://specific.dev). We believe you can move just as fast as you can with Supabase (whether you're a developer or not) if you just let coding agents code. What they are missing is the infrastructure parts, which we provide, like a private Postgres database that a backend can be built around (and which can't just be publicly exposed).
I find it kinda amusing that the only two times I've heard Supabase mentioned on here was the time that someone let Cursor delete their prod DB and this.
I understand it's some kind of RAD framework for JavaScript people?
I feel I might be showing my age here, but I don't understand how securing your production database is a challenge all of a sudden. (My hot take of the day)
It really sucks that Supabase is what LLMs default to. Supabase has an innate problem.
- RLS asks for way more discipline to use securely than the bog-standard "client+API+SQL db"
- Supabase has spent all of its marketing budget on beginners (pre-LLMs) and completely non-technical users (post-LLMs)
This combination is always going to lead to complete trainwrecks. It's like marketing angle grinders to people who have never learnt to use a saw.
The chance of Supabase ever changing from RLS-first to RLS-last is near zero as well as it's too core to their brand. As long as it's RLS-first it doesn't matter how many "barriers" and "checks" they put up either. They will never put up enough to slow adoption, which is what would be needed.
It would be much better for everyone if the standard vibe coding stack was based on, for example, Cloudflare. Pages/Workers/D1 or something. Not that I'm a fan of CF (and there may be better alternatives) but at least it would cut these cases of "entire DB exposed" at least in half.
Another bit of irony is that the whole selling point of Supabase has been "time from zero to one", "less code/boilerplate required", "I'm a frontend developer and don't want to learn backend". But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
You hit the nail on the head.
> But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
This is precisely the approach we are taking for Specific (https://specific.dev). We believe you can move just as fast as you can with Supabase (whether you're a developer or not) if you just let coding agents code. What they are missing is the infrastructure parts, which we provide, like a private Postgres database that a backend can be built around (and which can't just be publicly exposed).
I find it kinda amusing that the only two times I've heard Supabase mentioned on here was the time that someone let Cursor delete their prod DB and this.
I understand it's some kind of RAD framework for JavaScript people?
I feel I might be showing my age here, but I don't understand how securing your production database is a challenge all of a sudden. (My hot take of the day)
Source: https://x.com/theonejvo/status/2017732898632437932