A non-technical family member is working on a tech project, and giving them Lovable.dev with Supabase as a backend was like complete magic. No amount of fiddling with terminals or propping up postgres is too little.
We technical people always underestimate how fast things change when non-technical users can finally get things done without opening the hood.
This is good and bad. Non-technical users throwing up a prototype quickly is good. Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad. It's easy for non-technical users to get a false sense of confidence if the thing they make looks good. This has been true since the RAD days of Delphi and VisualBasic.
I think there's going to be the same problems as there are fixing bad body shop code. The companies that pushed their "vibe code" for a few dollars worth of AI tokens will expect people to work for pennies and/or have unreasonable time demands. There's also no ability to interview the original authors to figure out what they were thinking.
Meanwhile their customers are getting screwed over with data leaks if not outright hacks (depending on the app).
It's not a whole new issue, shitty contractors have existed for decades, but AI is pushing down the value of actual expertise.
For nearly 50 years now, software causes disruption, demand drives labor costs, enterprise responds with some silver bullet, haircuts in expensive suits collect bonuses, their masters pocket capital gains, and the chicken come home to roost with a cycle of disruption and labor cost increases. LLMs are being sold as disruption but it's actually another generation of enterprise tech. Hence the confusion. Vibe coding is just PR. Karpathy knows what he's doing.
Genuinely, it's a lot better.
I beg to differ. Non-technical users pushing anything into production is GREAT!
For many, that's the only way they can get their internal tool done.
For many others, that's the only way they might get enough buyers and capital to hire a "real" developer to get rid of the security holes and non-obvious bugs.
I mean, it's not like every "senior developer" is immune from having obvious-in-retrospect security holes. Wasn't there a huge dating app recently with a glaring issue where you could list and access every photo and conversation ever shared, because nobody on their professional tech team secured the endpoints against enumeration of IDs?
I agree it is great that more people can build software, but let's not pretend there are zero downsides.
I agree with you on the downsides.
There was a reason the industry was regulated, and circumventing these reasons with an app has been a net negative to society.
If a user is confident enough about a no name company that they give them enough info to make identity theft a possibility, it was only a matter of time before a spammer/phishing attack gets them anyway
That's not convincing. Of the apps that do get used, the vibe-coded ones will likely be unsafe.
> If a user is confident enough about a no name company that they give them enough info to make identity theft a possibility
That's completely unrelated. You can give a company very little information. Any of it being leaked is unacceptable. You can find a lot from an email, or a phone number.
People are taught, by CNBC, by suits, by hacks, that you can trust the apps on your commercials and it will be fine. It likely won't be, and your response is exactly why. Many of you are apathetic to the idea of doing right by people.
So people are manipulated, and some of them are elderly and don't even understand how computers work. This is reason enough to care about what they are exposed to, not say "let's burn it all down with shitty vibe-coding because users are dumb anyway."
We're supposed to be better than this.
What's the threat though. As in, what's at risk. A leaked email address? Probably. Enough info to have your identity stolen as prior commenter had mentioned. Probably not.
> That's completely unrelated.
Umm, no, it's related due to the prior commenter claiming that was the risk in their contrived situation from prior post mentioning identity theft.
> Any of it being leaked is unacceptable. You can find a lot from an email, or a phone number.
Everyone's email has already been leaked somewhere. It's not private data. This is like saying your bank account number is confidential financial information and ignoring the fact it's printed on every check you write.
> Many of you are apathetic to the idea of doing right by people.
> We're supposed to be better than this.
I object by simply saying I'm just being realistic. Data leaks somewhere, everywhere, sometimes, always. You're choosing to live in a fantasy land where this doesn't happen as if it wasn't the very true state of the world long before vibe coding came along. Sure, it's not my ideal state. But it is the actual state of things. Get real.
That you think vibe coded apps may not collect PII, or that all PII has already been leaked is not at all realistic.
> This is the same thinking that PHP is unsafe thus can't use PHP.
No, it's not the same because you code in a programming language. You don't code with vibe code, you let something else tell you there's code and you don't look at it. It's different on every level. Unless you're copy-pasting without understanding the code, which, as far as I'm concerned, is just as bad.
> Meanwhile, PHP is running countless billions of commerce just fine every day.
It is famously *NOT* running just fine. It *CAN* run just fine. But the freedom of what you can do in PHP and the low barrier to entry has led to Frankenstein apps with higher than average security issues. I work in legacy software, lots of PHP apps.
You seem to be under the impression that people are saying all apps were secure before vibe coding. That is not the case. But the scale of risk is far greater. Programming safely requires diligence. Instead you're saying "well maybe if we pay even less attention to what we're writing, it will be just as safe." That's irresponsible.
> There's always a risk.
There's a risk of me dying in a car accident. That doesn't mean I'm going to let my toddler drive for me.
Even us entrepreneurially minded technical devs cut corners on our personal projects that we just want to through a Stripe integration or Solana Wallet connect on
And large companies with FTC and DOJ involved data breaches just wind up offering credits to users as compensation
so for non-technical creators to get into the mix, this just expands how many projects there are that get big enough to need dedicated UX and engineers
Feels we're skipping these steps and "generating" prototypes that may or may not satisfy the need and moving forward with that code into final.
One of the huge benefits of things like Invision, Marvel, Avocode, Figma, etc. was to allow the idea and flow to truly get its legs and skip the days where devs would plop right into code and do 100s of iterations and updates in actual code. This was a huge gain in development and opened up roles for PMs and UI/UX, while keeping developer work more focused on the actual implementation.
Feels these generate design & code tools are regressing back to direct-Code prototypes without all that workflow and understanding of what should actually be happening BEFORE the code, and instead will return to the distractions of the "How", and its millions of iterations and updates, rather than "What".
Some of this was already unfortunately happening due to Figma's loss of focus on workflow and collaboration, but seems these AI generation tools have made many completely lose sight of what was nice about the improved workflow of planning, simply because we CAN now generate the things we think we want, doesn't mean we should, especially before we know what we actually want / need.
Maybe I'm just getting old, but that's my .02 :).
you can vibe code a fully working UI+backend that requires way less effort so why bother with planning and iterating on the UI separately at all?
anybody who actually knows what they are doing gets 10x from these tools plus they enable non-coders to bring ideas to the market and do it fast.
My point isn't to stitch things to Figma, that's abhorrent to me as well. My point is to not get bogged down on the implementation details, in this case an actually working DB, those tables, etc, but rather less fidelity actual full flow concepts that can be generated and iterated.
Then that can be fed into a magic genie GPT that generates the front-end, back-end, and all that good jazz.
The thing is, the cost of producing websites is already pretty low, but the value of websites mostly derives from network effects. So a rising flood of micro crud saas products will not be likely to generate much added value. And since interoperability will drive complexity, and transformer based LLMs are inherently limited at compositional tasks, any unforeseen value tapped by these extra websites will likely be offset by the maintainability and security breaks I mentioned. And because there is a delay in this signal, there is likely to be a bullwhip effect: an explosion of sites now and a burnout in a couple of years in which a lot of people will get severely turned off by the whole experience.
If someone has the idea for the next Amazon, as well as everything else you need beyond the idea, and tools like Supabase and Lovable allow them to get it off the ground, those tools are incredibly valuable to that person.
If someone’s ideas are worthless, their websites will be worthless.
> you can vibe code a fully working UI+backend
…is gonna bring a lot of houses crashing down sooner or later.
One thing I will agree on though is that LLMs make it easier to iterate or try ideas and see if they'll work. I've been doing that a ton in my projects where I'll ask an LLM to build an interface and then if I like it I'll clean it up and or rebuild it myself.
I doubt that I'll ever use Figma to design, it's just too foreign to me. But LLMs let me work in a medium that I understand (code) while iterating quickly and trying ideas that I would never attempt because I wouldn't and be sure if they'd work out and it would take me a long time to implement them visually.
Really, that's where LLMs shine for me. Trying out an idea that you would even be capable of doing, but it would take you a long time. I can't tell you how many scripts I've asked ChatGPT or similar to write that I am fully capable of writing, but the return on investment just would not be there if I had to write it all by by hand. Additionally, I will use them to write scripts to debug problems or analyze logs/files. Again, things that I am perfectly capable of doing but would never do in the middle of a production issue because they would take too long and wouldn't necessarily yield results. With an LLM, I feel comfortable trying it out because at worst I'd burn a minute or two of of time and at best I can save myself hours. The return on investment just isn't there if it would take me 30 minutes to write that script and only then find out if it was useful or not.
PostgREST is quite boring, open source, proven tech.
E.g. Concur is primarily feature-complete and will only ever need to evolve gradually.
So the drawbacks of being brittle, kludged-together, and incapable of making rapid feature changes doesn't really matter.
In some other products, that matters a huge deal.
So the tl;dr is, as always, optimize for the things that actually matter for your particular situation.
But I had to abandon it after wasting weeks trying to do simple things. The biggest problem is the lack of documentation. Fundamental parts of the system are undocumented, like the User table. There's no doc on how the columns function, so I couldn't determine why a user is marked as "confirmed" (presumably through E-mail or other validation) immediately upon insertion to the table.
There's also no full documentation of client-library syntax. For example the Swift library: There are a few examples of queries, but no full documentation on how to do joins (for example).
And just try to use your own certificates; something that I've been doing for years during iPhone-app development was impossible with Supabase.
And why? Because these simple scenarios appear to be distant outliers for Supabase. It's as if nobody has ever brought them up before; and even if they have, nobody has been able to answer the first questions about them.
If you're not building a single-page Web app that just lets people browse a database, Supabase doesn't seem to envision your application.
So I went back to a plain Deno back-end, which is what I was building before trying Supabase. In the amount of time I wasted trying to scrounge up documentation and fruitlessly asking questions in forums and Discord, I was able to learn and implement authorization, and then get back to work building a product.
Maybe all this money will let the Supabase team hire some people to document their product.
You've only talked about 2 things : Lack of documentation (which I somewhat agree with) and using custom certificates. Custom certificates is not a "simple scenario" and I don't blame Supabase for not spending time on this. I fact I would prefer they work on other things (like documentation !).
"Lack of documentation" speaks to several apparently routine use cases being outliers; otherwise, they'd be documented. I already talked about the User table Supabase provides (and populates in unexpected ways), and about the Swift library that you have no reference for formulating joins through... another critical and expected ability.
Once you encounter a problem they either don't want to solve or haven't solved, your only choices are either:
- start layering on hacks (in which case you quickly get into case where no one and nothing else could help you)
- decide not to do that-thing
- do a rebuild to get rid of the batteries-included.
Personally I think something Supabase is great for toy projects that have a defined scope & no future or a very early startup that has the intention to rebuild entirely. Just my opinion though, maybe others feel more comfortable with that level of lock-in.
Even something like Heroku is miles better because they keep everything separated where your auth, database, & infrastructure aren't tightly coupled with a library.
Why not just throw AI at it? Seems to be the best use case. So get a startup to fix this startup…so on and so forth…
Citation: professional writer with technical writing experience (also out of work)
For me, that was a strong signal that everyone gave it a go, found it too difficult to generate quality stuff, and reverted.
Good luck to you regardless.
Good luck to you. I ended up at a company that makes non-software products but really wants (and needs) to modernize their doc-production pipeline.
It's Postgres, but bundled with some extensions and Postgrest. And a database UI. But hosted and it runs locally also by pulling the separate parts. Running it locally has issues though, so much so that I found it easier to run a docker compose of the separate parts from scratch and at that point just carry that through to a deployment, at which point is there still a reason to use Supabase rather than another hosted Postgres with the extensions?
It's a bit of a confusing product story.
Realistically 99% of the users would still be screwed if they ever shut down, regardless of if it's open (see: Parse)... but it gives people a some confidence to hear they're building on a platform that they could (strictly in theory) spin up their own instance of should a similar rug pull ever occur
I agree you might prefer to choose the stack yourself, but for total n00bs and vibe coders supabase is a great start / boilerplate vs say the MEAN stack that was a hit 5y ago
The developer experience is first rate. It’s like they just read my mind and made everything I need really easy.
- Deals with login really nicely
- Databases for data
- Storage for files
- Both of those all nicely working with permissions
- Realtime is v cool
- Great docs
- Great SDK
- Great support peeps
Please never sell out.
Is it the PostgREST part? Are you using it for simple queries, or are you trying to use it for complex business logic?
Asking because PostgREST is great when you use it the way it’s intended but like any tool it will underperform when used in a way it’s not supposed to. It’s a screwdriver that you shouldn’t use to hammer nails.
So no... PostgREST wasn't a factor for me at all.
I'm sorry you had a bad experience with this kind of tool, but I hope that one day you choose to revisit it.
So... what are you talking about?
To me this is a 100% philosophical opposition.
People find this tech useful. You might prefer writing your own backend. Claiming it doesn’t save time for people who use it to save time however doesn’t make much sense, does it?
> And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.
I didn’t say it was.
The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....
- remote state
- authoritative logic that can't run solely on the user's device because you can't trust it
- authentication
each of which is annoying when you're focused on building the user-facing app experience. Supabase solves all three without you needing to touch any infrastructure. The self-hosting thing just provides insurance that users are not completely locked in to their platform, which is a big concern when you're outsourcing basically your entire backend stack.
In the end I jumped into it wholeheartedly, mainly because I wanted a canned solution for authorization and user-confirmation. But soon I came up against obstacles I had easily overcome with plain Deno already, but were seemingly insurmountable with Supabase.
When one basic use-case after another turned out to be almost wholly undocumented and unexplored by the Supabase docs and community, I concluded that Supabase is really only suited for people building Web back-ends that let people browse a database.
As an application back-end, its marquee features don't add value or are basically irrelevant... as far as I can see. The rest of it is incomplete and/or undocumented, with client libraries being an example.
They are great products that cover 95% of what a CRUD API does without hacks. They’re great tools in the hands of engineers too.
To me it’s not about vibe coding or AI. It is that it's pointless to reinvent the wheel on every single CRUD backend once again.
I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns. Your entire schema is exposed. Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly. You're pushed into fake open source where you can't always run the software independently. Who knows what will happen when the VC backers demand returns or the company deems the version you're on as not worth it to maintain compared to their radically different but more lucrative next version.
I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
As a long-time Hasura stan, I can't agree with this in any way.
> Your entire schema is exposed
In what sense? All queries to the DB go thru Hasura's API, there is no direct DB access. Roles are incredibly easy to set up and limit access on. Auth is easy to configure.
If you're really upset about this direct access, you can just hide the GQL endpoint and put REST endpoints that execute GQL queries in front of Hasura.
> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper
> Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops
... How is an API that queries Hasura via GQL any different than an API that queries PG via SQL? Put your business logic in an API. Separating direct data access from API endpoints is a long-since solved problem.
Colocating Hasura and PG or Hasura and your API makes these network hops trivial.
Since Hasura also manages roles and access control, these "extra hops" are big value adds.
> You're pushed into fake open source where you can't always run the software independently
... Are you implying they will scrub the internet of their docker images? I always self-host Hasura. Have for years.
> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
I think your arguments pretty much sum up why people think it's just about backend engineers feeling threatened - your sole point with any merit is that there's one extra network leg, but in a microservices world that's generally completely inconsequential.
Backends are far messier (especially when built over time by a team), more expensive and less flexible than a GraphQL or PostgREST's api.
> I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns
Writing backend code without knowing what you're doing is also an insecure nightmare that forces anti-patterns. All good engineering practices still need to apply to Hasura.
Nothing says that "everything must go through it". Use it for the parts it fits well, use a normal backend for the non-CRUD parts. This makes securing tables easier for both Hasura and PostgREST.
> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly
I'm gonna disagree a bit with the sibling post here. If you think that going through Hasura for everything is not working: just don't.
This is 100% a self-imposed limitation. Hasura and PostgREST still allow you to have a separate backend that goes around it. There is nothing forbidding you from accessing the DB directly from another backend. This is not different from accessing the same database from two different classes. Keep the 100% CRUD part on Hasura/PostgREST, keep the fiddly bits in the backend.
The kind of dogma that says that everything must be built with those tools produces worse apps. You're describing it yourself.
> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
I have heard the arguments and all I hear is people complaining about how hard it is to shove round pieces in square holes. These tools can be used correctly, but just like anything else they have a soft spot that you have to learn.
Once again: "use right tool for the job" doesn't mean you can only use a single tool in your project.
What sounds like the worst of both words to me is forcing Supabase/Hasuea to do what it isn’t good at or force a traditional backend to do the same thing those tools can do but taking 10x of the time and cost.
My experience was super positive and saved a lot of coding and testing time. The generated APIs are consistent and performant. When they don’t apply, I was still able to use a separate endpoint successfully.
Exactly. This is one of the things I never understood about Supabase's messaging: The highly-touted, auto-generated "RESTful API" to your database seems pointless. Why would I hard-code query logic into my client application? If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.
Why would anyone do this?
Both those techs might make this look convenient, but engineering rules must still be followed.
Frontend should do validation and might have some logic that’s duplicate for avoiding round-trips… but anything involving security, or that must be tamper-proof, must stay in the server, or if possible be protected by permissions.
There are whole classes of applications that can be hosted almost entirely by Supabase or Hasura. If yours isn’t, it doesn’t mean you should force it.
I also didn't mention security, let alone promote moving it to the front end.
The answer is: you wouldn’t. That’s not the point of any of those tools.
What is the point of an auto-generated HTTP API to the database, if not to let clients formulate queries? And why would you do that?
If "letting the client formulate queries" you mean "filter posts by DidYaWipe, sorting by date", this is also what traditional CRUD backends do.
If PostgREST auto-generates three-table joins automatically to resolve many-to-many relationships and presents an appropriate endpoint, that's interesting.
To avoid the above problem, it's a standard practice in PostgREST to only expose a schema consisting of views and functions. That allows you to shield the applications from table changes and achieve "logical data independence".
For more details, see https://docs.postgrest.org/en/v12/explanations/schema_isolat....
1. If your function returns a table type, you can reuse all the filters that PostgREST offers on regular tables or views [1].
2. The SQL code will be much more concise (and performant, which leads to less maintenance work) than the code of a backend programming language.
3. The need for migrations is a common complaint, but you can treat SQL as regular code and version control it. Supabase recently released some tooling [2] that helps with this.
[1]: https://docs.postgrest.org/en/v12/references/api/functions.h...
[2]: https://supabase.com/docs/guides/local-development/declarati...
Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail.
Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database.
Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.
Congratulations: that's not basic CRUD anymore, so you ran into the 5% of cases not covered by an automatic CRUD API.
And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time.
You don't have to throw the baby away with the bathwater just because it doesn't cover 5% of cases the way you want.
It's a rite of passage to realize that "use the right tool for the job" means you can use two tools at the same time for the same project. There are nails and screws. You can use a hammer and a screwdriver at the same time.
How do you balance the nail and screw? I'm serious, I'm trying to picture this, hammer in one hand, screwdriver in the other, and the problem I see here is the nail and screw need to be set first, which implies I can't completely use them both at the same time.
Perhaps my brain is too literal here, but I can't figure how to do this without starting with one or the other first
Some projects require nails, other require screws, some might require both.
Instead of hammering screws (or in this case reinventing a screwdriver), just use an existing screwdriver. That’s what I mean: don’t reinvent the solved problem of CRUD endpoints when applicable to the endpoint. Nothing says you can’t use two techs per project.
There are 2 parts to using Fireabse, the client SDK and the admin SDK.
The client SDK is what's loaded in the front end and used for 95% of use cases like what u/whstl mentions.
The adminSDK can't be used in the browser. It's server only and is what you can use inside a custom REST API. In your use case, the email verification loop has to happen on a backend somewhere. That backend could be a simple AWS lambda that only spins up when it gets such a verification request.
You're now using a hammer for the front end and a screw driver for the finer details.
The equivalent to Firebase's "Client SDK" is just the PostgREST API, which needs to be secured.
The equivalent to Firebase's "Admin SDK" is the PosgreSQL connection string that can be used like a normal PostgreSQL.
EDIT: What I’m advocating here is the opposite: use those tools for CRUD so that your frontend looks exactly the same as a frontend with a regular backend would. If the tool is not good for it (like the example), just use a regular endpoint in whatever backend language or framework. Don’t throw the baby (the 95%) with the bathwater (the 5%).
By “just use a normal endpoint” I mean “write a normal backend for the necessary cases”.
At least when used correctly, but honestly I can’t see a situation where it’s easy to do otherwise for queries.
The utility is in not having to write a lot of repetitive endpoints in a traditional backend, for a large amount of endpoints.
What exactly do you mean by “query logic in the client code”?
In PostgREST, if userMessages is a table in itself, you do get an endpoint called /userMessages.
If the table is called messages and you want to get messages from a user, you can just request something like /messages?user_id=123. And if user_id must your own user_id, you can just skip passing the parameter, thanks to RLS.
If userMessages requires is a join between two tables and you don't want to let the frontend know about it, you can use a view and PostgREST will expose the view as an endpoint.
Once again, there is no "need" to formulate joins in the frontend to reap the benefits of this tool.
I don't do anything close to "formulating a join in the client" with PostgREST and I still use it to its full extent, and it does save time.
EDIT: If one wants to formulate more complex joins in the frontend, then they probably want something like Hasura instead. Once again: complex queries in the frontend is BY NO MEANS mandatory, you can still use flat GraphQL queries and db views for complex queries. PostgREST OTOH is about keeping it simple.
It feels like it's Open Source mainly for the sake of good PR, not to be actually useful.
It’s been so long that new ideas are solving parts on the access spectrum without seemingly being aware of it.
Supabase and others would have a smaller footprint to add an app layer and reporting layer to their tool since it is data as the cornerstone not an afterthought