[hackitup7]

I'm sure that a lot of the l33t h4x0rs here think that Supabase sucks and is only for amateurs but I'll say that as a former engineer who's getting back into building fun side projects again, Supabase has been incredible and just what I wanted. It's my favorite new product that I've started using in the last year. I hope they build out an enormous TAM of people who don't want to live inside a terminal and make a ton of money.

[sebastiennight]

I was looking for this comment.

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.

[asnyder]

Back in the day we'd call this phase a design and workflow prototype as to not have to deal with all the technical components until the actual flow and concept is done.

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 :).

[_zoltan_]

there is no need to this tedious, boring phase which you miss, especially since it still requires a significant of coding effort (eg to stitch a backend to figma).

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.

[asnyder]

That's always been the justification to skip this phase :). Tools have just changed. One-person to small-team wonders that could code and build directly made the same arguments.

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.

[namaria]

If the effort to produce websites goes tends to zero, the value of websites will surely tend to zero. Either issues with security and maintainability will be a break on this tendency or we will get to a point where generating a custom website will be something trivial that will be done on demand.

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.

[gdilla]

If you need a website that needs prototyping in 2025, you're probably doing it wrong (eg launch on insta or something). But anyway, you can vibe iterate, and not just small iterations, but wholesale different value props and approaches, so why not. it's tangible, easier to test, and you get more meaningful feedback. I do this and it's 3-4x faster than working with a designer. And to be sure, we're not making websites, but protyping features into a saas app to test with users and ourselves.

[bluesnowmonkey]

The value of Amazon.com is not the cost to produce the HTML and JavaScript you see when you visit that website. It is a component of the Amazon business, and to Amazon it is extremely valuable, and to everyone else it would be almost worthless.

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.

[biztos]

Don’t get me wrong, I love Supabase, but

> you can vibe code a fully working UI+backend

…is gonna bring a lot of houses crashing down sooner or later.

[joshstrange]

I couldn't agree more. "Vibe coding" is pretty cool, but it's not sustainable at least with with current technology. You're much better off being a knowledgeable developer who can guide an an LLM to write code for you.

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.

[namaria]

LLMs are better search. Google burned down the house to keep itself warm and held off on LLMs until it was inevitable and are now pulling up ahead. This is the logical conclusion. LLMs will be monetized and enshitified by ads.

[whstl]

The whole point of Supabase is not needing to vibe code the backend part.

PostgREST is quite boring, open source, proven tech.

[codr7]

So they say; I still haven't seen any high quality vibe coded software, and I'm pretty sure I never will.

[Aeolun]

I’ve seen tons of low quality successful software (concur anyone). Clearly being well built is not a requirement for success.

[ethbr1]

I'd split the difference and say the cons that low quality software creates only matter sometimes.

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.

[itissid]

This can only be true of some products. Often there are a lot of concerns like privacy, white labeling, legal consequences that need to be considered _before_ you vibe code.

[giantrobot]

> 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.

[sally_glance]

Knowing the industry I'm pretty sure they will all push those AI prototypes to production - because they did the same with non-AI prototypes before. Now the question is once they inevitably pull in experienced folk for maintenance, refactoring and debugging, will it be easier or harder than working with that retired solo devs spaghetti codebase?

[giantrobot]

From looking at "vibe coding" tools their output is about the quality of bad body shop contractors. It's entirely possible for experienced devs to come in and fix it.

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.

[sally_glance]

Yeah, the current trend has lots of parallels to the low code/no code trend we had a couple of years back and the workflow engine trend we had about 15 years back... I'm curious why you think it would push down the value of engineering hours though, that didn't even happen in the past.

[nyarlathotep_]

> From looking at "vibe coding" tools their output is about the quality of bad body shop contractors.

Genuinely, it's a lot better.

[namaria]

I think this is just another correction. The software market is worth several trillion dollars now. Enterprise is pushing against the rise in labor costs. It will backfire as it did every single time and in a few years competent developers will be worth their weight in platinum.

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.

[sally_glance]

50 years might be overstating it a bit, lookup tables/hash maps were a novelty back then and available compute resources increased by many orders of magnitude... So maybe we actually had some real enablers in the meantime. My gut feeling is the current AI hype is at least as revolutionary as search engines, marketplaces or social networks (not like recommendation engines or block chain). Though not as revolutionary as the loom or electricity

[yieldcrv]

I don't think its bad enough

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

[kangaroozach]

This suggests a strong need for AI powered code security review and patching as a compliment to Agentic coding platforms. Ideally, in parallel to your coding, it could scan your GitHub and output specific tasks for the Agentic AI to perform for you.

[sebastiennight]

> Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad.

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?

[somebehemoth]

What about users who sign up for these insecure apps and have their data and possibly their identity stolen due to the misplaced trust? That this already happens is no excuse to encourage even less security by encouraging novices to believe they are experts.

I agree it is great that more people can build software, but let's not pretend there are zero downsides.

[conductr]

This is a contrived situation. Most of the apps in discussion see little to no use and go dead soon after launch. The vast majority are collecting little data of negligible risk.

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

[Capricorn2481]

> Most of the apps in discussion see little to no use and go dead soon after launch

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.

[sebastiennight]

My feeling is that this is similar to saying, "non-professional AirBnB hosts are a terrible security nightmare, and the fact that people are not much safer in regulated hotels is no excuse to encourage even less security by encouraging novices to play in the hospitality business".

I agree with you on the downsides.

[namaria]

AirBnB externality is not the safety risk for guests (although I personally ended up in some sketchy situations years ago, I don't use it anymore, mainly because:) the real externality is imposed on the inhabitants of popular tourist destinations.

There was a reason the industry was regulated, and circumventing these reasons with an app has been a net negative to society.

[DidYaWipe]

I really wanted to like Supabase, and decided to adopt it as the back end for a mobile app I'm building. So... I was invested to some extent.

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.

[kangaroozach]

Let’s hope that a tiny portion of the $200M goes towards documentation. If they spent $5k on professional writers they could get something useful. For $50k something great. And for $500k they could have an entire suite of highly produced explainer videos with great post production.

[6stringmerc]

$5k won’t even get you native English language writers, $50k might get you one. One decent writer…for 6 months. Y’all really don’t know the value of skilled non software engineer professionals do you?

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)

[jvanderbot]

My mom was a writer all her life. The last 5 years she's done more and more editing. After LLMs kicked off, and I mean to the month of them starting to hit headlines her work plummeted, then spiked with tons of garbage, and is now levelling off with her usual workflow.

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.

[DidYaWipe]

You are on the money. I just went back to technical writing after decades in software development for, well, some very very well-known companies.

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.

[Jean-Papoulos]

>Because these simple scenarios appear to be distant outliers for Supabase

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 !).

[DidYaWipe]

It is 100% a simple scenario. I can't speak for Android, but you have to use HTTPS now for calls in an iPhone app if you want to get it approved. That means you need to deploy certificates to your test devices, simulators, and development machine.

"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.

[madamelic]

That is the root of the problem with these batteries-included frameworks: lock-in.

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.

[cpursley]

By comparing supabase to Heroku, you demonstrated that you don't actually understand what it is...

[highwaylights]

Having worked with it quite a bit I'm still not sure I really understand what it is, which sounds like a bizarre sentence but:

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.

[jonplackett]

I really love supabase. And I’m glad they are getting some funding because I’m terrified they’ll get bought by Amazon or google and completely ruined.

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.

[DidYaWipe]

I have no idea where you're finding "great docs" and "great support," because the lack of both of those drove me away from Supabase after having invested quite a bit of time and effort in it.

[whstl]

Which parts did you have a problem with?

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.

[DidYaWipe]

I didn't see any purpose to the PostgREST part as a back end to an application, because I'm not going to hard-code queries in my application. My server is going to provide an API that isolates the application from the DB structure.

So no... PostgREST wasn't a factor for me at all.

[steve-chavez]

> My server is going to provide an API that isolates the application from the DB structure.

The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....

[whstl]

It seems your opposition to it is philosophical and/or based on assumptions (that one must "hard-code queries in the application"), or limitations of Supabase's Swift library.

I'm sorry you had a bad experience with this kind of tool, but I hope that one day you choose to revisit it.

[mindwok]

The product story is that people want to build apps and naturally find themselves having to handle:

- 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.

[madeofpalk]

it's just a firebase competitor, that's based on postgres and you can run sql against it if you want.

[eddieroger]

It's also implied, and proven by some, that having access to Postgres means you can up and leave Supabase if you want to later. It won't be snap-your-fingers easy, but it's more direct than other hosted SaaS where you can't access your data or the schemas.

[swyx]

that "just" is carrying a lot of weight there

[peab]

exactly this

[DidYaWipe]

Totally agree. I read all kinds of articles and posts and asked for opinions and explanations, to see if I should use Supabase to build a back end for a mobile app.

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.

[csomar]

You are not wrong that it’s a postgres + extensions. However, the tech market is very big now and that can sustain these valuations.

[BoorishBears]

Not really a confusing story: it's a PaaS that wants to beat fears of becoming another Parse (https://www.willowtreeapps.com/craft/parse-shutdown-what-it-...)

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

[tough]

They have also been giving back to postgres some of their extra work, and also their real time stuff i think is on erlang?

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

[whstl]

I’ve been using Hasura and PostgREST for a few years now with real big production apps, in enterprise and in startups, and honestly the only problem with them is that backend engineers feel threatened.

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.

[TSiege]

Experienced backend dev here who also uses Hasura for work at a successful small business. I think it's great at getting a prototype to production and solves real business problems that a solo dev could do by himself. As engineer #2 it's a mess, and it doesn't seem like a viable long term strategy.

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

[DidYaWipe]

"Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper."

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?

[steve-chavez]

> 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.

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....

[DidYaWipe]

Thanks. If you're writing functions, though, it seems like nearly as much work as writing traditional endpoints, no?

[steve-chavez]

Not really, the work is much reduced.

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...

[whstl]

Nobody but you is forcing you to put the “business logic” in the frontend.

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.

[DidYaWipe]

Who said anything about forcing? I asked what the value of Supabase's most highly-touted features are, when they CATER TO the movement of such things as query logic to the front end. What else are you doing with an auto-generated RESTful HTTP "API" to the database?

I also didn't mention security, let alone promote moving it to the front end.

[whstl]

You are the one mentioning “Why would I hard-code query logic into my client application?”

The answer is: you wouldn’t. That’s not the point of any of those tools.

[nawgz]

> As engineer #2 it's a mess

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.

[whstl]

I completely disagree.

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.

[LinXitoW]

I've only played with these kinds of plug and play databases, but mixing and matching seems like the worst of both worlds. The plug and play is gone, because some things might me in API 1, some others in API 2, and maybe worst of all, their domains might overlap. So you need to know that the "boring" changes happen via the postgREST, but the fancier ones via some custom API. The APIs will probably also drift apart in small ways, making everything even more error prone.

[whstl]

What you say is also true for situations where you us an ORM vs queries, or some direct MVC approach vs business service libraries which are common in backend apps. Or even having two different sets of APIs.

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.

[highwaylights]

I like PostgREST for some of it's use cases (views mostly), but the issue I have with it is that I don't often want a user to have direct access to the database, even if it's limited to their own data.

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.

[whstl]

> 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

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.

[no_wizard]

>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

[SenHeng]

I'm going to answer this using Firebase, which Supabase is supposed to be a copy of.

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.

[whstl]

Yep. Exactly the same for PostgREST/Supabase.

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.

[whstl]

At the same time: in the same project.

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.

[DidYaWipe]

Why would you hard-code queries into your client application?

[whstl]

I never said anything of the sort, what are you talking about?

[DidYaWipe]

"...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."

[NewJazz]

I have used them too, and I would say that at least for Hasura, performance can be poor for the generated queries. You have to be careful. Especially since they gate metrics behind their enterprise offering.

[whstl]

This is the same for any GraphQL backend. And even REST backends can be misused: I've fixed way too many joins-in-the-frontend that were causing N+1 queries in lists.

[ctm92]

When you use their SaaS offering, it's a good product. Self hosted is a different story. Massive stack that reinvents the wheel for every component, lack of documentation, breaking changes between versions all the time (although this has gotten better lately).

It feels like it's Open Source mainly for the sake of good PR, not to be actually useful.

[j45]

World still needs a replacement for Microsoft Access on the web.

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

[WuxiFingerHold]

I consider myself as fairly technical and don't think Supabase or Neon are sucking, but that they're getting quite expensive once you need a mid size DB. If I'd only need a small DB I'd hesitate not a second to get one of them.

[mrcwinn]

Elite hacker here. Supabase is excellent.

[isaachinman]

Not until/unless it has proper offline-first support. Check out InstantDB and Triplit.

[kirso]

Its the same h4x0rs who would build facebook in a weekend but they didn't

[digital_sawzall]

How much are you paying per month?

[horns4lyfe]

I’m with you, supabase is a fantastic product.

[nprateem]

It's all fun and games until you need caching - something that comes at unspecified cost from when I looked into it.

[sfblah]

So you're saying it's something like an updated version of Yahoo Small Business?

[spullara]

It is really good for getting started but ultimately our companies transition off of it.