alt.hn

4/22/2025 at 3:17:23 PM

Supabase raises $200M Series D at $2B valuation

 https://finance.yahoo.com/news/exclusive-supabase-raises-200-million-112154867.html

by baristaGeek

4/22/2025 at 3:38:38 PM

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.

by hackitup7

4/23/2025 at 4:10:23 AM

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.

by DidYaWipe

4/23/2025 at 9:09:41 AM

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.

by kangaroozach

4/23/2025 at 3:42:54 PM

$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)

by 6stringmerc

4/25/2025 at 5:57:53 AM

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.

by DidYaWipe

4/23/2025 at 10:00:33 PM

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.

by jvanderbot

4/23/2025 at 6:47:47 AM

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

by Jean-Papoulos

4/23/2025 at 7:55:52 AM

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.

by DidYaWipe

4/23/2025 at 1:10:29 PM

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.

by madamelic

4/22/2025 at 4:12:41 PM

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.

by sebastiennight

4/22/2025 at 5:50:56 PM

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

by asnyder

4/22/2025 at 6:18:43 PM

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.

by _zoltan_

4/22/2025 at 6:31:10 PM

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.

by asnyder

4/22/2025 at 9:24:19 PM

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.

by namaria

4/23/2025 at 2:08:00 PM

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.

by gdilla

4/23/2025 at 3:53:17 AM

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.

by bluesnowmonkey

4/22/2025 at 8:42:36 PM

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.

by biztos

4/22/2025 at 9:09:55 PM

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.

by joshstrange

4/22/2025 at 9:26:42 PM

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.

by namaria

4/23/2025 at 1:54:40 AM

Soon, some free smart LLM code generators will stop generating certain outputs and instead suggest using commercial components that have paid for promotion.

by sakesun

4/23/2025 at 5:43:59 AM

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

PostgREST is quite boring, open source, proven tech.

by whstl

4/22/2025 at 11:06:04 PM

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

by codr7

4/22/2025 at 11:21:45 PM

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

by Aeolun

4/23/2025 at 12:20:59 AM

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.

by ethbr1

4/22/2025 at 7:26:24 PM

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.

by itissid

4/22/2025 at 4:40:35 PM

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

by giantrobot

4/22/2025 at 4:52:39 PM

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?

by sally_glance

4/22/2025 at 7:52:36 PM

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.

by giantrobot

4/23/2025 at 6:36:49 AM

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.

by sally_glance

4/23/2025 at 12:10:22 AM

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

Genuinely, it's a lot better.

by nyarlathotep_

4/22/2025 at 9:32:48 PM

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.

by namaria

4/22/2025 at 9:39:04 PM

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

by yieldcrv

4/23/2025 at 9:12:42 AM

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.

by kangaroozach

4/22/2025 at 5:07:21 PM

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

by sebastiennight

4/22/2025 at 5:19:58 PM

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.

by somebehemoth

4/22/2025 at 10:40:09 PM

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

by conductr

4/22/2025 at 11:42:43 PM

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

by Capricorn2481

4/23/2025 at 6:04:35 AM

> Of the apps that do get used, the vibe-coded ones will likely be unsafe.

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.

by conductr

4/23/2025 at 2:02:25 PM

Vibe coded apps are by definition less secure. The more vibe coded apps, the more risk to users' data. Nothing you've said changes these facts.

That you think vibe coded apps may not collect PII, or that all PII has already been leaked is not at all realistic.

by somebehemoth

4/24/2025 at 5:01:18 PM

This is the same thinking that PHP is unsafe thus can't use PHP. Meanwhile, PHP is running countless billions of commerce just fine every day. Sure, vibe coding has most likely not gone through some common sense checks for security. SQL injection is likely higher risk, XSS risks, etc. But I just don't believe your assertation of risk is realistic either. There's always a risk.

by conductr

4/25/2025 at 4:49:43 PM

I use AI and PHP, so I'm not someone unfamiliar with either.

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

by Capricorn2481

4/22/2025 at 6:20:05 PM

[flagged]

by _zoltan_

4/22/2025 at 7:14:07 PM

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.

by sebastiennight

4/22/2025 at 9:36:48 PM

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.

by namaria

4/22/2025 at 6:10:59 PM

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.

by highwaylights

4/22/2025 at 7:24:59 PM

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.

by jonplackett

4/23/2025 at 4:13:59 AM

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.

by DidYaWipe

4/23/2025 at 5:46:54 AM

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.

by whstl

4/23/2025 at 8:00:28 AM

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.

by DidYaWipe

4/23/2025 at 2:23:54 PM

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

by steve-chavez

4/25/2025 at 5:52:48 AM

Thanks for the reference. I'll take a look.

by DidYaWipe

4/23/2025 at 8:47:51 AM

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.

by whstl

4/25/2025 at 5:52:01 AM

"Seems" how? I gave specifics, not assumptions. I already explained WHY an auto-generated HTTP API to your database caters to the hard-coding of queries in the application. And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.

So... what are you talking about?

by DidYaWipe

4/25/2025 at 6:47:41 AM

You keep saying “this does X which is bad” while at the same time saying “if it doesn’t do X it is useless”.

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.

by whstl

4/22/2025 at 11:26:31 PM

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.

by mindwok

4/22/2025 at 6:13:58 PM

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

by madeofpalk

4/22/2025 at 7:17:23 PM

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.

by eddieroger

4/22/2025 at 9:29:19 PM

that "just" is carrying a lot of weight there

by swyx

4/22/2025 at 6:38:47 PM

exactly this

by peab

4/22/2025 at 6:56:49 PM

[dead]

by InstaPage

4/23/2025 at 4:22:17 AM

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.

by DidYaWipe

4/22/2025 at 6:40:14 PM

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

by csomar

4/22/2025 at 6:17:48 PM

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

by BoorishBears

4/22/2025 at 6:51:32 PM

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

by tough

4/22/2025 at 5:13:24 PM

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.

by whstl

4/22/2025 at 6:16:21 PM

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

by TSiege

4/23/2025 at 4:28:22 AM

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

by DidYaWipe

4/23/2025 at 2:16:17 PM

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

by steve-chavez

4/25/2025 at 5:41:42 AM

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

by DidYaWipe

4/25/2025 at 6:23:47 PM

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

by steve-chavez

4/23/2025 at 5:25:01 AM

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.

by whstl

4/23/2025 at 5:34:30 AM

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.

by DidYaWipe

4/23/2025 at 5:51:09 AM

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.

by whstl

4/23/2025 at 7:51:53 AM

Yep, I'm the one. And the question stands.

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?

by DidYaWipe

4/23/2025 at 8:23:50 AM

PostgREST creates the same type of CRUD endpoint that one would create when writing a traditional backend with an (eg) MVC framework, and it does this without requiring a developer and with complete consistency.

If "letting the client formulate queries" you mean "filter posts by DidYaWipe, sorting by date", this is also what traditional CRUD backends do.

by whstl

4/24/2025 at 7:46:07 AM

I wouldn't write a back end with an MVC framework, since it's not doing any presentation whatsoever.

If PostgREST auto-generates three-table joins automatically to resolve many-to-many relationships and presents an appropriate endpoint, that's interesting.

by DidYaWipe

4/22/2025 at 6:34:14 PM

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

by nawgz

4/22/2025 at 6:47:58 PM

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.

by whstl

4/22/2025 at 10:59:58 PM

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.

by LinXitoW

4/23/2025 at 5:28:27 AM

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.

by whstl

4/22/2025 at 6:19:10 PM

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.

by highwaylights

4/22/2025 at 6:34:03 PM

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

by whstl

4/22/2025 at 10:22:09 PM

>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

by no_wizard

4/23/2025 at 7:05:59 AM

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.

by SenHeng

4/23/2025 at 8:50:53 AM

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.

by whstl

4/23/2025 at 5:20:39 AM

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.

by whstl

4/23/2025 at 4:32:36 AM

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

by DidYaWipe

4/23/2025 at 5:18:06 AM

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

by whstl

4/23/2025 at 5:27:07 AM

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

by DidYaWipe

4/23/2025 at 5:30:09 AM

Where in my message does it say or imply that you should “hard code queries in your client application?”?

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

by whstl

4/23/2025 at 5:36:55 AM

Of what use is an "automatic CRUD API" if you're not putting query logic in your client application?

by DidYaWipe

4/23/2025 at 5:56:00 AM

With Supabase or Hasura you would write the same client code you would write if you were using a traditional backend.

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”?

by whstl

4/23/2025 at 7:50:52 AM

I mean instead of doing a GET on an endpoint called userMessages with an ID parameter, you're formulating a join in the client between specific tables.

by DidYaWipe

4/23/2025 at 8:35:36 AM

That's not necessarily true.

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.

by whstl

4/24/2025 at 7:42:50 AM

Thanks for the reply. If your database is normalized to any degree and you have multi-way relationships, I don't really see significant payoff from the auto-generated API vs. writing traditional queries and endpoints.

by DidYaWipe

4/22/2025 at 6:02:04 PM

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.

by NewJazz

4/22/2025 at 6:51:40 PM

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.

by whstl

4/23/2025 at 10:44:31 PM

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.

by ctm92

4/22/2025 at 10:37:47 PM

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

by j45

4/23/2025 at 3:44:38 AM

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.

by WuxiFingerHold

4/24/2025 at 8:51:52 AM

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

by kirso

4/22/2025 at 9:04:14 PM

Elite hacker here. Supabase is excellent.

by mrcwinn

4/22/2025 at 10:28:57 PM

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

by isaachinman

4/22/2025 at 4:50:01 PM

How much are you paying per month?

by digital_sawzall

4/22/2025 at 11:00:08 PM

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

by horns4lyfe

4/22/2025 at 6:40:39 PM

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

by nprateem

4/22/2025 at 9:47:53 PM

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

by sfblah

4/22/2025 at 7:48:18 PM

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

by spullara

4/25/2025 at 8:14:00 PM

[dead]

by canadianfella

4/22/2025 at 3:25:13 PM

That’s a lot of money.

What’s Supabase’s exit strategy? Are they sustainable long term as a standalone business?

You can also see how money is starting to chase “vibe coding” — as long as you say the magic words, even if your product is only tangentially related to it, you can get funding!

by otterley

4/22/2025 at 3:31:31 PM

Reading the tea leaves, Series D means they opted for more funding vs IPO. They claim to have 2 million users, but they're open core so how many are paying? Maybe their books aren't looking that great. Wall street doesn't understand database vendors outside of "big data", so they're probably hoping for acquisition. Not sure who would buy them though, as PostgreSQL vendors are kind of a dime-a-dozen these days...

by candiddevmike

4/22/2025 at 3:39:40 PM

If lovable, bolt.new, etc kept integrating with them, that's a money maker without needing to do much sales. There's a wave of AI tools that require somehow save state and Supabase provides that. I'm absolutely amazed others haven't jumped in the same ship yet.

by clvx

4/23/2025 at 11:42:10 AM

In the short term yes, but why would you as an end user of lovable and similar tools prefer expensive Supabase? If you already have an AI developer at your disposal you might as well make it figure out how to properly set up and maintain AWS, right? Maybe it can't do it now -- too complicated because there's no simple AI-accessible interface, and LLM models are simply not smart enough yet, but I imagine it will change soon.

by StrandedKitty

4/22/2025 at 5:15:08 PM

That definitely seems to be the play. Keep funneling in users from Lovable/bolt.new and keep building revenue or hope to be acquired if one of those vibe coding tools gets huge.

by philomath_mn

4/22/2025 at 3:43:24 PM

> Not sure who would buy them though, as PostgreSQL vendors are kind of a dime-a-dozen these days...

Supabase defo has a much higher mindshare.

by adamnemecek

4/22/2025 at 4:23:23 PM

Sure but ultimately they're still just selling something that is already free and wrapping AWS. These business models aren't sustainable unless you trash your free product, which also isn't sustainable. Presumably they have a good deal with their cloud vendor, AWS I think, but I think its safe to assume they lose A LOT on their free products.

by TechDebtDevin

4/22/2025 at 4:49:22 PM

The whole premise of cloud hosting businesses is that people don't want to manage stuff themselves.

by adamnemecek

4/22/2025 at 5:09:56 PM

They end up managing stuff themselves anyway. Plus managing another kind of bills.

by hirako2000

4/22/2025 at 6:27:14 PM

AWS seems to be doing fine.

by adamnemecek

4/22/2025 at 6:22:53 PM

> so how many are paying

This is like if Google Spanner were open sourced tomorrow morning: realistically how many people are going to learn how to deploy a thing that was built by Google for Google to serve an ultra-specific persona?

Maybe you might get some Amazon-sized whale peeking at it for bits to improve their own product, but the entire value prop is that it's a managed service: you're probably going to continue paying for it to be managed for you.

by BoorishBears

4/23/2025 at 1:51:51 AM

IMO it also depends on how the whole process is tied together.

I always loved Vercel for their easy hosting of Next.js with included CI/CD, but I recently switched to self-hosting - their pricing switched from a flat, worry-free $20/month to an unpredictable whatever-it-may-cost plus it sent me 10+ emails every single month about hitting some quotas that they introduced and I couldn't find a good way to stop that.

by badestrand

4/22/2025 at 5:35:20 PM

A lot are paying, including me for multiple projects. They have a pretty good offering. I used to use them for dev and prod, but now using neon for dev. Supabase still for prod. I had switched from mongo to supabase. I may switch to neon for prod but not in a rush.

They also offer so much more than just postgres. Though I use them only for postgres myself.

by firtoz

4/23/2025 at 1:23:10 AM

Since you use both supabase and neon, any particular strength or weakness to keep supabase for prod? I just moved my app to neon today (easy enough to test it!) and am enjoying the auto-scaling features and UI is great on neon. But I'm curious about how supabase stacks up.

by drewnick

4/23/2025 at 1:44:09 PM

A lot of people don't self-host it, even though it is open core. This is due to their docs being garbage and tons of differences between the offerings, so you can't even rely on the main docs if you're self-hosting.

It's easier to just become familiar with a DB UI tool like Beekeeper or DataGrip and spin up your own things. I'm also not a huge fan of being "locked-in" to so many things (including their auth). I think most projects would be better off keeping these parts separated, even if they are using third-party services to handle them, as it would be way less overhead to migrate out.

by alp1n3_eth

4/22/2025 at 10:30:01 PM

it's an aggressive preemptive round, so i'd guess 2b/50 = 40M of revenue. Probably low margins since the free tier/ hosting postgres nature of the business.

by tschellenbach

4/22/2025 at 3:33:04 PM

> What’s Supabase’s exit strategy? Are they sustainable long term as a standalone business?

Acquisition best case, Private Equity worst case.

Do you see Supabase going public on the stock market? Perhaps unless they do what Cloudflare done and are replicating AWS, it may be hard to see a stock market debut.

Could be wrong though.

by colesantiago

4/22/2025 at 3:38:30 PM

Supabase is basically AWS Postgres under the hood. It's popular amongst hobbyists and small teams but I'm not sure whether any large teams actively use it. Once you're past the point of serious business, it's much more cost effective to host everything by yourself.

by fakedang

4/22/2025 at 5:04:25 PM

Supabase at is minimum providing a PostgreSQL server, pooler (they started on pgbouncer, how their own) and a PostREST API, and support, backup, logging etc. You can be doing serious business and not have the time/people to run these reliably self-hosted. They also provide Auth almost to the Auth0 level and Edge functions like Vercel, S3 like storage (sharing the db's permission system), and websocket/presence backed by Elixir. TBH they are a compelling value, at least for us.

by ZiiS

4/22/2025 at 8:44:52 PM

Granted, Supabase does provide a lot under the hood, and it's excellent for whipping out a quick MVP, but I wouldn't count it production ready even today, simply because of the downtime I've experienced at times (even if their dashboards say otherwise). And it's not just an isolated case - a lot of folks on reddit complain with the same issues. Perhaps your treatment is different because of the high spend you guys have.

by fakedang

4/22/2025 at 4:39:49 PM

What is serious business? I think supabase can scale brilliantly, and it doesn't lock you in, if you have need for some special infra you can build and integrate it, I don't know but you could possibly even use FDW to access a postgres you run yourself.

Also they can't run on AWS postgres with all their postgres plug-ins AFAIK.

The point of "cheaper to host everything yourself" is a lot higher than what most estimate.

My only concern is that is supabase goes out of business or go evil you're gonna have a bad time, however everything is open-source

by carlhjerpe

4/22/2025 at 8:41:11 PM

Serious business is when you need to maintain uptime and stability. Not just me, but a lot of folks on the Supabase reddit have complained often about the insane downtimes that we've experienced at times with the platform. I would 100% use it for prototypes and MVPs, but for production? Neither me nor a lot of others would touch it with a pole, even though I'm sure your experience might be different.

by fakedang

4/22/2025 at 5:30:14 PM

My former place ran a lot of RDS Postgres but also loved Supabase. It's more than just hosted DB because it has loads of value adds like web-based table editing, auth, edge functions, row-level security, easy hooks and triggers. We were capable of operating RDS but the cost of operations in dev hours was high. Supabase was super easy for moderate price and readily compatible with our RDS and Redshift.

by tootie

4/22/2025 at 8:46:32 PM

I don't disagree. Supabase does provide a lot of functions under the hood that one would have to build out individually otherwise. I really like their lock-in model - you're not locked in with your data, but because of the extra functionality that they provide to your database.

by fakedang

4/22/2025 at 3:33:25 PM

> Are they sustainable long term as a standalone business?

It's bananas to me that questions like these could be unanswered even 5 years after the business started. This possibly cannot be the most efficient way for finding new solutions and "disrupting" stale industries?

by diggan

4/22/2025 at 3:35:26 PM

> It's bananas to me that questions like these could be unanswered even 5 years after the business started.

Those are rookie numbers, Discord is coming up on 10 years old and has made zero dollars to date, yet is supposedly considering an IPO soon.

by jsheard

4/22/2025 at 3:46:28 PM

It's very common for tech companies to go public without being profitable. As long as their growth is good and they have a reasonable story for how they will achieve profitability, then it typically makes sense. Of course every company is different and not all will reach their profitability goals post-IPO, but in many cases, it wouldn't make sense to wait for profitability before going public.

by vecter

4/22/2025 at 5:11:23 PM

Also reasons they need to go public. Growth is costly.

by hirako2000

4/22/2025 at 4:11:15 PM

Discord has a fairly successful subscription product that is generating tens of millions in revenue. They most certainly have made more than 0 dollars. Profitable? Less likely.

by hashamali

4/22/2025 at 4:14:09 PM

Yeah I meant zero profit, poor wording on my part.

by jsheard

4/22/2025 at 11:26:28 PM

Discord has the user growth to make up for it. It’s practically a household name on the level of Google now. I see many people boosting servers too, so clearly they are making a bunch of money.

by Aeolun

4/22/2025 at 4:10:29 PM

The IPO is how (the shareholders) make money, by selling to bagholders.

by bombcar

4/23/2025 at 7:03:08 AM

> This possibly cannot be the most efficient way for finding new solutions and "disrupting" stale industries?

The thing is, the people with far more information than we have, and with actual money on the line, think this is a good use of their money. They're not always right, of course, but the industry as a whole is profitable and is innovative and "disruptive".

So, yes, this can be a good way for finding new solutions. The most efficient? IDK but it's the best we've come up with so far.

by edanm

4/22/2025 at 4:12:33 PM

What's really bananas is that your comment is just as relevant today as it would have been 15 years ago. It's been bananas for a while now.

by jihadjihad

4/22/2025 at 4:54:58 PM

Google bought firebase, so my guess is they are aiming for an Amazon or Microsoft acquisition.

by FloorEgg

4/22/2025 at 7:19:09 PM

To be fair, their $2B valuation is probably the most reasonable valuation we've seen in years. That doesn't negate the question of how they plan to turn a profit.

If they truly have 3.5 million databases, that's only ~$500 per database to recoup the investments, that doesn't seem to crazy. Companies like OpenAI or Twitter/X are never going to be profitable enough to cover what they've already spend/cost. Supabase could because the amount is so much lower and they have paying customer, but I'd like to emphasize the "could".

by mrweasel

4/22/2025 at 3:35:13 PM

Acquisition. All of these VC companies raise unsustainable levels of money in hopes of acquisition or IPO. Supabase seems to be leaning towards acquisition.

by 9283409232

4/22/2025 at 3:35:06 PM

They are definitely creating some value. Managed database.

by returnInfinity

4/22/2025 at 11:34:36 PM

"ROI? Return on Investment?"

"No, Radio on the Internet."

by NoTeslaThrow

4/22/2025 at 7:11:01 PM

and setting up postgresql on a simple VPS is so easy... You can literally ask Gemini 2.5 Pro or o3 or Sonnet 3.7 and do it in 15-30 minutes... Learned helplessness is really something and vibe coding is overrated imo: https://www.lycee.ai/blog/why-vibe-coding-is-overrated

by fsndz

4/22/2025 at 8:29:02 PM

i'm a bit brain fried right now but are you being sarcastic? typing out apt-get install postgresql is a lot less that 15-30min.

by chasd00

4/23/2025 at 5:36:37 AM

Yes, but setting up e.g. users and pg_hba might be something you would need to research before doing your first postgres deployment even if you previously came from a managed postgres service. Also coming up some sort of backup strategy would be a good idea.

But once you know these things, you could of course be faster.

by alex23478

4/22/2025 at 5:56:04 PM

The greater fool strategy has worked well for unprofitable tech companies for decades, and shows no signs of slowing down

by nikanj

4/22/2025 at 6:45:25 PM

> Are they sustainable long term as a standalone business?

Was Meteor? They are exactly the same thing. And I really liked Meteor!

To me, the more money pouring in, the better. That said:

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRCVKYR...

(The Silicon Valley Economy cartoon)

by doctorpangloss

4/22/2025 at 3:34:24 PM

What an absolute joke. Their exit strategy is presumably to keep chasing the high and find more ways to integrate AI. The era of building good software for fun and profit is coming to an end.

by lionkor

4/22/2025 at 4:05:21 PM

I think their product is sound, they build essentially a backend as a service platform on open-source software. That doesn't make it easy to run at scale, so you probably wanna use their paid offering unless you plan to hire a lot of staff to maintain it, but it is possible and they support small scale dev envs

by carlhjerpe

4/22/2025 at 4:55:20 PM

100% this; we have a 4 digit monthly spend. I guess I will double-check when we reach 5 digits, but I can't afford my own time self-host it yet.

by ZiiS

4/22/2025 at 8:37:25 PM

Have you thought about possibly hiring a junior engineer to make the transition possible? I don't know what your use case but creating a solution that fits your needs would be worth it IMO. You're already spending a years worth of dev salary which can get you plenty of good talent around the world with.

by azemetre

4/22/2025 at 4:00:40 PM

>Supabase is currently used by two million developers who manage more than 3.5 million databases. The startup supports Postgres, the most popular developer database system that’s an alternative to Google’s Firebase. Supabase’s goal: To be a one-stop backend for developers and "vibe coders."

How many of those users are paid. You can sign up for free without a credit card.

It's cool, for certain use cases. I ended up trying it for a few months before switching to Django.

If you ONLY need to store data behind some authentication, and handle everything else on the frontend, it's great. Once you need to try some serverside logic it gets weird. I'm open to being wrong, but I found firebase phenomenally more polished and easier to work with particularly when you get to firebase functions compared to edge functions.

Self hosting requires magical tricks, it's clearly not a focus for them right now.

I hope they keep the free tier intact. While it's not perfect, if your in a situation where you can spend absolutely no money you can easily use it learning ( or for portfolio piece).

by 999900000999

4/22/2025 at 4:16:27 PM

> Self hosting requires magical tricks

Has anything changed recently? ~1year ago I installed a local instance (that I still use today for logging LLM stats) and IIRC all I had to do was "docker compose up". All the dockers are still starting for me at boot from that 1yo install, to this day. (I use it on 127.0 so no SSE & stuff, perhaps that's where the pain points are? Dunno, but for my local logging needs it's perfect).

by NitpickLawyer

4/22/2025 at 4:43:05 PM

Hosting it on an actual server with a URL is not a fun experience. You need to generate a specific type of string to get it to work.

This isn't documented anywhere. Deep deep in their GitHub issues you'll find a script for generating this magic string which needs to be set as an environment variable.

See https://github.com/supabase/supabase/issues/17164#issuecomme...

by 999900000999

4/22/2025 at 6:06:47 PM

Looks like it is just an issue of correctly making a jwt token, if you are not using their client libraries, but you can also just do it via their docs https://supabase.com/docs/guides/self-hosting/docker#generat... now (not sure how long you've been able to do in the docs)

by Zekio

4/22/2025 at 10:52:32 PM

Sure "it's in the docs" but last time our devops tried the compose file with ~10 or so services it took several days of fiddling with all sorts of different issues. It is just not made for selfhosting at all. It can be so much simpler but JS devs like it different.

by k4rli

4/23/2025 at 10:55:11 PM

It has gotten a bit better lately, but it's still a pain.

Just recently the docker-compose stack from the current main branch would not start properly, because someone committed a faulty health check. Why does this make it to the main branch, does nobody there review PR?

Starting a new stack is nothing compared to maintaining it. Upgrading to newer images requires carefully checking which environment variables suddenly appeared in new versions or maybe were renamed. Upgrades never really went absolutely smooth for me in the past.

by ctm92

4/23/2025 at 4:35:49 AM

Try using your own certificates. It's easy with Deno (for example) but as far as I could tell impossible with Supabase. Certainly it's undocumented, and that's a huge problem if you want to do real development.

by DidYaWipe

4/22/2025 at 4:04:00 PM

It’s normal Postgres. There’s no need to handle everything on the front end. The tutorials nudge you to learn RLS and use their SDKs for the client, but you can write perfectly normal server side code as well.

by scosman

4/22/2025 at 4:14:03 PM

Yeah I’ve ran a small project where I just did everything with the “service account” credentials which operates like a normal Postgres connection.

by teaearlgraycold

4/22/2025 at 4:16:36 PM

If you're not supporting users, it's fine.

But if you usecase involves Supabase auth, using a service account to bypass RLS is kind of like hardcoding connection strings.

by balls187

4/22/2025 at 9:45:51 PM

You can use both properly and together.

The service account should only be accessed on the service.

If using Auth+Server, you can check the verified user identity via Auth JWTs (or something, see the docs).

Yeah, don't use the server connection on the client, but they have many warnings against that.

by scosman

4/22/2025 at 4:18:04 PM

I literally use it because it's a free hosted postgres database. I just connect via connection string on my backend and run the queries there.

by groguzt

4/22/2025 at 4:14:23 PM

Yeah, it's a bit wonky, especially when you are dealing with configuring specific combination of supabase/deno/typescript features (e.g. stage 2 vs stage 3 decorators)

by balls187

4/22/2025 at 4:20:17 PM

How is Djanjo a replacement for Supabase?

by TechDebtDevin

4/22/2025 at 4:50:38 PM

For my current project I basically need a backend server for processing some basic game logic.

I had done something similar in Firebase and it was easy. Supabase wasn't straightforward here. It got to a point where I'm sure I could eventually get it working, but I also think I'm outside the expected usecase.

Django is much more flexibility in this regard.

by 999900000999

4/22/2025 at 3:54:45 PM

Congrats team!

I was a speaker in a local Supabase event just few weeks ago, https://shorturl.at/JwWMk. We had a local event in Abuja, Nigeria. There we promoted their Launch Week 14 series, highlighting new features from Supabase. In reality, it became an event to show people how to bootstrap a quick backend for their SME business in a weekend.

by kaladin_1

4/22/2025 at 3:30:36 PM

Is the new valuation multiplier number of developers on platform instead of revenue? Valuing at $1000/developer is kind of insane. Valuing at $570/database is also nuts. It's a cool product but I hope the founders can find a win in what must be a pretty cramped cap table.

by film42

4/22/2025 at 4:59:57 PM

Their 2024 revenue was estimated at $16.8M [1] and $10.5M in 2023. If you extrapolate that growth rate +1 year you can assume it's now $26.9M. Another source estimates it at $15M in 2025 [2].

So if you assume their revenue is in that range, you're looking at 66x to 133x ARR multiple. In today's market that's quite a big markup. Standard SaaS right now is probably more like 5-15x. AI is a lot more (but Supabase isn't AI). But they are a key leader in their market, so probably get a meaningful bonus for that. And I'm sure a lot of big industry investors were competing against each other for the Supabase deal, so that definitely would have helped valuation too. Also, at their maturity today, they are probably showing some great success signing big enterprise deals and telling a story about how that will grow.

That being said, those factors alone don't answer 66-133x. Perhaps Supabase's strongest angle is their opportunity for product-led growth:

- They have a huge number of people on a free tier

- The growth rate of free tier users might be accelerating

- The conversion rate of free tier users to paid users might also be increasing

- They're adding more things that people can pay for, increasing LTV of customers. e.g., for my business, we probably 20x our Supabase cost in the last 6 months - most of that is due to our growth but also there are a lot of things we can buy from Supabase beyond compute.

So I would assume, in addition to the above, they're telling a story about their actual revenue growth rate will accelerate meaningfully because of all of these factors working together.

Lots of assumptions in here, but you can start to see how a lot of different factors + a hype multiple could lead to such a valuation.

[1] https://getlatka.com/companies/supabase.com#revenue

[2] https://leadiq.com/c/supabase/5ed1e4778a998f161ef62998

by acrooks

4/23/2025 at 4:22:01 PM

A $2B valuation with revenue roughly between $15M-$25M a year. Is this normal? Seems insane to me. And I love Supabase!

by jc_811

4/22/2025 at 3:35:50 PM

Their series C was in September 2024!

by candiddevmike

4/22/2025 at 3:41:43 PM

I've been a lukewarm user of Supabase for my side projects. Unfortunately the amount of work to get off of it has been too high for me to leave.

The major issue is - cost. It is way more expensive than I realized as they have so many little ways they charge you. It's almost like death by thousands of paper cuts. My bill for my app with just a few thousand users was $70 last month.

I do like the tooling and all, but the pricing has been very confusing.

by k2xl

4/22/2025 at 3:47:41 PM

Kind of the same feeling, I don't use all of services they offer either and when I looked at self-hosting, it all seemed kind of heavy and fragile to self-host. I ended up replicating the parts I used with a small API layer connected to a managed postgres db for a tenth of the cost or something. I'd say it's pretty handy for prototyping but not sure I'd want to build a business on the back of it.

by jamil7

4/22/2025 at 10:07:09 PM

> just a few thousand users was $70 last month.

Few Thousand!?! Sound very reasonable to me. Monetize just two of those users at $35 per month and your server costs are covered. Or run it yourself, there's a lot of moving parts but it's all open source.

by cpursley

4/22/2025 at 11:47:42 PM

> Few Thousand!?! Sound very reasonable to me. Monetize just two of those users at $35 per month and your server costs are covered

That's one way to look at it, but compared to any other way to run a server, it's objectively terrible. You can serve that many users with a $5 box.

by Capricorn2481

4/23/2025 at 12:31:46 AM

So put Supabase on a $5 box or build out your own replacement backend if your time is that cheap.

by cpursley

4/23/2025 at 9:39:23 AM

I think i mentioned this in my original reply- the app was already built and too integrated with supabase, it is hard to leave

by k2xl

4/23/2025 at 11:33:35 AM

It's open source, self host it. Or find some paying customers.

by cpursley

4/23/2025 at 12:25:38 PM

That's quite challenging to do. I've myself spent quite a few hours looking into it and came to the conclusion that they make it their goal to complicate the self-hosting by lack of detailed docs. For example: I recall seeing a comment/warning in their docs similar to "for production, don't use this default setup" and it kinda felt more like "tough luck, figure it out or fork out $ome ca$h". Perfectly fine business model, but not 100% self-hostable on a production level (even for a very basic app)

by a-l-e-c

4/23/2025 at 3:21:34 AM

This is exactly the reason I’ve been avoiding it despite seeing it mentioned all the time. I’m sure I’m missing out on some conveniences but it’s just too cheap to host my own pg DB. I can deal with backups and auth if it means saving a not so insignificant amount of money per month.

by replwoacause

4/22/2025 at 9:05:47 PM

$2B valuation at $16M revenue sounds nuts..

My prediction: They're banking on a big exit to OpenAI or Claude as the defacto backend for an AI IDE.

They're the only big alternative to Firebase, and Firebase just got pulled into Google AI Studio.

by saxelsen

4/22/2025 at 9:15:21 PM

where did you get 16M revenue?

by dangoodmanUT

4/23/2025 at 7:37:47 AM

Someone else mentioned it in the comments. A quick google gives some websites that estimates their revenue to that within +/- 5M

by saxelsen

4/22/2025 at 6:06:06 PM

I've been testing out PostgREST, RLS, and PL/pgSQL functions for a new app and I'm not wild about it. It's pretty complicated to grok the permission model, it's awkward to load up your DB with logic, and the LLMs kinda suck at reliably generating working queries, policies, functions, etc. So I'm not really convinced it's ideal for 'vibe coders'.

by siliconc0w

4/22/2025 at 4:08:58 PM

Personally think that supabase and vercel are giving AWS a run for their money, and will start to eat into their market share. The developer experience is far superior to AWS, in a way that cannot be argued away by AWS handling "more complexity and scale". Supabase/Vercerl products are superior to large cloud providers, and while they target a narrower aspect of the tech stack, and to smaller customers, they will expand into more enterprise as their users grow.

AWS needs to get their act together and start prioritizing developer experience

Also, supabase is looking like the go to database for ai created apps. Which will be a major tailwind

by codingwagie

4/22/2025 at 4:19:08 PM

I think large companies/gov contractors will still prioritize compliance and control systems over DX.

And I believe both Supabase and Vercel run all their services on AWS anyways, so AWS gets paid no matter what.

by gabinator

4/22/2025 at 4:33:02 PM

Both use AWS under the hood

by xmorse

4/22/2025 at 4:49:22 PM

point still stands

by codingwagie

4/22/2025 at 6:30:52 PM

How are they giving AWS a run for their money when they use AWS for their own service? AWS profits from Supabase growth.

by ru552

4/22/2025 at 6:44:24 PM

AWS is unusable in alot of cases.

by codingwagie

4/22/2025 at 8:45:00 PM

But it doesn't matter because they are transitively being used by virtue of Vercel/Supabase being on them. They could definitely charge more, that's for sure, but it's not like they don't get a pretty penny from others building atop them

by 5Qn8mNbc2FNCiVV

4/22/2025 at 10:03:37 PM

Right but they run on AWS. So AWS is making money every time someone uses Vercel or Supabase

by chipgap98

4/22/2025 at 9:25:08 PM

Good for them. They get so much hate online I think because it’s such a “why didn’t I think of that” idea. People are jealous of their success I feel.

by hfgjbcgjbvg

4/22/2025 at 3:37:18 PM

Raising a very late funding stage in the private market to avoid an IPO in the violent public market I presume? I’m guessing this is the new startup norm for a while, along with reducing burn or exiting at a big discount if not just dying

Nevertheless congrats to the Supabase team!

by jameslk

4/22/2025 at 4:14:08 PM

Execs cashing out some of their shares to buy houses in Tahoe while the stock market is in the red.

by vrosas

4/22/2025 at 3:50:48 PM

I love Supabase, but this seems to be the sign they will not be available in next 2-3 years. Or get acquired by someone.

I don't think this is a good sign.

by desireco42

4/22/2025 at 3:26:03 PM

I always felt like they’re the database dogman would use.

by zhoujianfu

4/22/2025 at 4:32:31 PM

Time to vibe code the data into "That supa awesome database over there"

by sophrocyne

4/22/2025 at 7:46:47 PM

As someone with a seven year old, I appreciated this. Thank you.

by jedberg

4/23/2025 at 12:08:15 AM

Nice, I gotta admit, I like seeing new stuff get funded like this - but man, whenever I read about crazy big rounds, I start wondering how these companies ever make real money vs just chasing hype till the next exit. Always makes me think about what actually lasts long term besides just burn and churn.

by gitroom

4/22/2025 at 3:32:24 PM

Why do they bring up vibe coding here. They are just a firebase alternative and Google has way superior ai code gen tools

by Mortiffer

4/22/2025 at 3:41:32 PM

Supabase is quite well integrated with vibe coding tools - cursor, replit, v0, etc. I agree that Firebase is a superior well-integrated product, but IMO the vibes are on Supabase side.

by justanotheratom

4/22/2025 at 3:36:07 PM

My guess is that they got that insane overvaluation because they sold themselves as an AI company

by lionkor

4/22/2025 at 6:28:38 PM

My humble guess is they sold themselves as the enabler for the AI vibe coding "revolution"

by ru552

4/22/2025 at 6:54:31 PM

I'm convinced the only profitable market for these DB companies is enterprise.

Either that or they need to add features and products alongside the DB to essentially replace the likes of Vercel.

Having said that Supabase is probably the best 'cloud DB' I've played around with so hope they succeed.

by crowcroft

4/22/2025 at 10:05:56 PM

I built a 'serverless' platform that's similar, smaller but more focus on low-code than Supabase https://saasufy.com/

All the components are declarative HTML and update in realtime. Similar concept as HTMX but doesn't require any backend code. You can still implement complex UX, authentication, access control and filtered views (indexing and all).

I built this app with it over a few months as a weekend project: https://www.insnare.net/app/#/onboarding/country/All

by socketcluster

4/22/2025 at 11:31:43 PM

A 'serverless' platform that's "similiar". But not open source, and uses a token to 'own a piece of it'?

Care to explain what the idea behind this is and where you see the similarities?

by beeman

4/22/2025 at 4:07:58 PM

This seems like another one of those VC companies which gets pushed by the VCs to the other companies in their portfolios as a probable integration point.

The whole growth of vibe coding really did help them because I don't think actual developers use it because putting things like functions in the database and authorization in the database is something that we learnt a few decades ago is a bad idea.

So I would guess they are used by massive amounts of developers who are new to coding or do not fully know how to code, but are becoming developers and who love the free databases Supabase provides.

Would love to know what is their actual revenu.

by ilrwbwrkhv

4/22/2025 at 5:47:18 PM

> The whole growth of vibe coding really did help them because I don't think actual developers use it because putting things like functions in the database and authorization in the database is something that we learnt a few decades ago is a bad idea.

Why are those things a bad ideas? You could be right but if you insist on making value judgements without explanation or elaboration, you're going to sound like a whiny old crank who is scared of becoming obsolete.

by fasbiner

4/22/2025 at 6:15:40 PM

What I mean is that, you know, we tried all of these things back in the day. Like putting your business logic in a database was something that was tried. It's not that the first time that these ideas have shown up. And they were basically tried and tested and found faulty. But now there's this whole new generation of sub-bar developers. And they are being fooled into thinking that all of this works because they just want to get their hands dirty. I guess when normies flood the scene the wolves make a killing.

by ilrwbwrkhv

4/22/2025 at 6:51:15 PM

As an observation, the quotations and the article itself doesn’t appear very thoughtful or well reasoned. It sounds more like a VC wanted a big deal (or at least to represent it as such) and made a bet, invited his buddies(?) along, and the company has seen a recent bump from “vibe coding”. Some allusion to Larry Ellison. Very light on information to form an opinion…

by jbs789

4/22/2025 at 3:41:58 PM

I'm from the future again, and I predict that either Replicate or fal.ai will get acquired by one of these so-called 'Vibe-coding' companies. Supabase included.

When I see valuations like this, they are overvalued until they use that money to acquire another company for a total addressable market expansion.

by rvz

4/22/2025 at 4:28:19 PM

It's really sad that nobody is actually trying to be a real company these days. When Steve Jobs was asked that if he will ever sell Apple, he physically recoiled and scolded the person asking such things. Nowadays, all of these companies are being set up just to be acquired. Nobody has any ambition anymore to be long lasting, profitable and an actual business.

by ilrwbwrkhv

4/22/2025 at 5:20:33 PM

So basically the nobody wants to work of the business longevity world? What is the actual difference? If their goal is profitability and eventually retirement why not do it on an accelerated timescale and exit with millions in their 30s instead of hundreds of thousands in their 70s?

by cab11150904

4/22/2025 at 6:38:26 PM

I think FAL is already too big for a "viber" company to buy. $55M ARR and 10%+ EBITDA. They're either going to IPO or get acquihired by a big 4.

by ru552

4/22/2025 at 7:07:41 PM

FAL team is the real deal, they will absolutely not get acquired by any of these other "vibes" companies.

by peterldowns

4/22/2025 at 6:37:31 PM

I'm sure the team might not be expecting this level of valuation. These trends won't last long. Make hay while the hype shines. Who knows how soon people would forget that there was something called vibe-coding and a back-end development.

by zkmon

4/23/2025 at 3:40:19 PM

Named after a Nicki Minaj song…what could go wrong? Just no concern whatsoever for creators or their brands. SupaCringe but not like I can do anything about it.

by 6stringmerc

4/22/2025 at 4:06:25 PM

I don't quite understand the high valuation. I use Supabase for the database and file storage (legacy choice). But those seem interchangeable. Are people using many many more features, if so how?

by sergiotapia

4/22/2025 at 4:50:26 PM

Not to be negative, but that seems super huge for its worth. How can you even recoup that with barely anyone paying? Founders trying to exit is comprehensible, but how can VCs sign this deal?

by h1fra

4/22/2025 at 4:51:03 PM

I don't really understand supabase. Everyone talks about how great it is, but it's just slow expensive postgres? I must be missing something.

by rozap

4/22/2025 at 8:25:39 PM

It has a nice web interface, comes with support for auth (which almost all apps need), and has a couple other nice things like storage buckets and serverless functions. When doing a hobby project, I don't want to rent a server from hetzner, set up SSH, connect, figure out how to install postgres, make sure everything is configured and so on. It's much nicer to click one button in the supabase UI and have everything I need

by ChadNauseam

4/23/2025 at 12:49:01 AM

I'm a happy Supabase customer. It's not just postgres, it's postgres + auth + functions + storage all in one place, with a very good local Docker environment and a variety of nice client SDKs.

It's a quick/convenient way to get a "full" backend up and running. The other option (Firebase) can't be self-hosted and has some absurd pricing footguns.

by nmfisher

4/22/2025 at 5:57:55 PM

It's slow expensive postgres _with_AI_

by nikanj

4/22/2025 at 8:43:53 PM

And the decline of a good product begins because it will be all about profits for board members going forward...

by unhappy_meaning

4/22/2025 at 8:55:01 PM

To be fair this is a series D

by constantlm

4/22/2025 at 8:08:03 PM

> The startup supports Postgres, the most popular developer database system that’s an alternative to Google’s Firebase

I've always taken issue with branding Supabase as an alternative to Firebase. Firebase is a PaaS whereas Supabase is more of a BaaS.

by joshdavham

4/22/2025 at 10:02:47 PM

can you explain more?

by chaosprint

4/23/2025 at 12:20:30 AM

While Supabase does support many equivalent Firebase features like a database, auth, functions, storage, etc, Supabase doesn't support website hosting whereas Firebase does. Supabase is mainly for backend stuff (BaaS) whereas Firebase is for both frontend and backend (PaaS).

To get the equivalent functionality of Firebase, you'd need to add something like Netlify or Vercel to pair it with your Supabase backend.

by joshdavham

4/23/2025 at 4:39:49 AM

Whatever those are.

by DidYaWipe

4/22/2025 at 9:20:46 PM

Retool uses Supabase for its out of the box database setup

by radicaldreamer

4/23/2025 at 3:45:47 AM

Proof? Highly doubt this.

by truetraveller

4/22/2025 at 3:35:14 PM

Congrats to Anthony and the team! What an amazing milestone.

by janosch_123

4/22/2025 at 5:20:36 PM

Crazy that devs choose supabase and vercel when Google Cloud is right there.

Google were late to the game but they've built perhaps one of the easiest cloud platforms to work with.

by factsaresacred

4/22/2025 at 6:12:41 PM

Do you use firebase?

by bze12

4/22/2025 at 5:07:26 PM

The only that hasn't changed in this industry is that engineers apparently can't stand new, green beginners getting into the field.

"They ship buggy, insecure messes" "They don't know how to fix what AI gave them" etc etc etc

Right. Like that same thing hasn't been happening literally during the entire existence of programming. I, for one, welcome the vibe coders. I hope it grows their interest in the field and encourages them to go deeper and learn more. Will some be lazy and not even try? Of course! Will some get curious and learn the ins and outs? Absolutely.

by jordanmorgan10

4/23/2025 at 5:33:49 AM

Supabase lacks doc, gitops.

by revskill

4/22/2025 at 9:12:26 PM

The thing I believe least in this article is that the investor is betting their career on this investment. Maybe they think that, but they’re still multi-millionaires making bets with other people’s money. They’ll be fine.

by sailfast

4/23/2025 at 5:13:53 PM

Hehe he’s signalling his high conviction to get those in after him and keep the valuation rising!

by jbs789

4/22/2025 at 3:51:00 PM

please fix the drizzle- --> supabase integration.

by inside_story

4/22/2025 at 10:08:07 PM

What's even the point of using drizzle with supabase? Isn't the entire point of supabase PostgREST and convenience tooling around it?

by cpursley

4/22/2025 at 4:52:45 PM

Congratulations to anyone who can raise $200m, let alone have the VCs fly around the world to make it happen.

by asim

4/22/2025 at 4:27:44 PM

Another heroku in the making. Also - where do these millions go? All into engineering?

by wg0

4/22/2025 at 5:39:20 PM

The new age is back

by hfgjbcgjbvg

4/22/2025 at 3:58:55 PM

A recent project on HN declared Supabase dead: https://www.isthistechdead.com/supabase

While the funding is impressive, I haven’t come across too many people touting Supabase or using it in production.

by awb

4/22/2025 at 4:08:53 PM

We had a pretty bad experience with it on a NextJS app and had to gut it out (I decided not to charge the client for this multi-week refactoring effort to pull out Supabase since it was upon my recommendation that they went with Supabase, so that decision actually cost us thousands of dollars).

It is good to get started and no doubt useful for simple CRUD apps. But once you want to start doing more complicated stuff, a lot of the RLS primitives become very hard to maintain and test, for example. You could say that that's Postgres's fault, but Supabase strongly pushes you in that direction.

The tooling, while looking quite polished, just felt pretty half baked along with docs (at least a year ago when we pulled the plug). Try to implement even a halfway complicated permissions scheme with it and RLS and you are in for a world of hurt and seemingly unmaintainable code.

So we ditched Supabase Auth for AuthJS, and are using vanilla postgres with Prisma. That's worked well for us. All the tooling is relatively mature, it's easy to write tests, etc.

Maybe if AI is writing some of the code, it might get easier, but for now, I'm avoiding Supabase like the plague until I see a project that's relatively complex that's actually easy to maintain.

by atonse

4/22/2025 at 6:58:09 PM

Agree, also the logging is very limited across the board,, database functions are impossible to debug without good logging, I think a lot of people don't realize its not a direct copy of Postgres, for the cloud version several Postgres functions are disabled by default.

by wyck

4/22/2025 at 5:28:37 PM

Nice to see others using Prisma in the wild! Prisma is the first ORM I've ever used (after decades of trials) that I actually enjoy using.

by herpdyderp

4/22/2025 at 4:20:50 PM

We're currently using supabase in production. I was already planning to leave them. I feel like it's close to good, but still really does have a _lot_ of bugs. It really doesn't feel like it's been tested thoroughly, and the documentation, while present, leaves a lot to be desired.

My experience of supabase really demonstrates to me that the ideals of all of the postgres layer technologies - postrest, realtime via wal, jwt auth in the db -, just don't make for an easy experience. It all works (mostly) but I find it more annoying than useful and have to work around it more often than I'd like. I suppose I'm old school, but just building the things that one needs is often more robust and less work than trying to plug into what they've provided.

I really don't know what they're going to do with a series D. It seems they now _have_ to go for a high-value exit, but I really don't see which company would provide that exit.

by brettnak

4/22/2025 at 5:51:24 PM

I had similar experience with everything missing that final attention to detail and polish and having to write issues and ask other how they got past certain problems. I ended up switching to Pocketbase, and while it is not a complete or drop in replacement hosted service, it is light weight and approachable to feel comfortable that it can scale and be more stable long term.

by murdockq

4/22/2025 at 6:16:35 PM

You should try Convex. It’s a better, higher level abstraction than Supabase.

by xixixao

4/22/2025 at 4:08:58 PM

Also HN consensus: Word Press with 40%+ of the web is dead, Firefox with less than 5% of desktop and 0% of mobile is thriving and AI is a fad.

by slig

4/23/2025 at 5:50:47 AM

I find it ironic that a project using Supabase declared Supabase dead (if you press F to pay respects, you get an error message that their Supabase is hammered and try again later).

by solatic

4/22/2025 at 4:30:17 PM

Imagine being a Postgres developer and getting 1% of that while being the core technology powering all these startups

by xmorse

4/22/2025 at 6:57:07 PM

Most of the heavy hitters in Postgres development are already sponsored by companies to do their work. Supabase has at least one Postgres committer on staff for instance.

by tristan957

4/22/2025 at 5:36:10 PM

[flagged]

by daemonk

4/22/2025 at 6:40:35 PM

i dont want to listen to uninformed "AI-generated" music any more than i want to support uninformed "AI-generated" code

by GuinansEyebrows

4/22/2025 at 10:05:47 PM

Sure. But it's not really about you. I wouldn't break into someone's house and tell them they painted their house an uninformed color.

If something sucks or won't scale, it will sort itself out in the market.

by daemonk

4/22/2025 at 11:18:31 PM

> I wouldn't break into someone's house and tell them they painted their house an uninformed color.

but if you, an experienced professional painter, were hired to repaint somebody's house, and that person used bad paint (or something else entirely, like... i dunno, shellac, or white glue), your scope of work changes from "light prep and paint" to a much more involved job of undoing the previous work (or mistakes) and then getting to the original scope of work.

> If something sucks or won't scale, it will sort itself out in the market.

i truly don't mean this in a derogatory way but that sounds incredibly naive.

by GuinansEyebrows

4/23/2025 at 1:00:11 AM

I don’t think we are going to agree on this.

At the end of the day we are really just disagreeing on how seriously we should take AI-ification of software engineering.

I take a lighter stance that it’s mostly harmless and has a lot of educational positives. I guess you foresee a lot of potential harm.

I do appreciate people who are willing to be the canary in the coal mine. I just find that a lot of the criticism appears to be more gatekeeping than legitimate worries.

by daemonk

4/23/2025 at 1:11:57 AM

I think folks can gatekeep because of legitimate worry :)

by GuinansEyebrows

4/22/2025 at 5:50:05 PM

A lot of comments seem to take issue with Supabase being aligned to Vibe-coding, which is understandable, but I do think it's related! I think vibe-coding could very well be a real market-force, and as best as I can tell it exists within a specific type of tech circle. No one is vibe coding Elixir, no one is vibe coding Rust, people are vibe coding React + Node/Python, and more specifically I think people are watching streamers and YT videos on hot-new-frameworks-near-you and want to try them out! Supabase is absolutely a darling of this tech-circle, and I think a few other companies could be as well:

1. oxc (oxlint)

2. vercel

3. fly.io

probably more! and more every day

by frankfrank13

4/22/2025 at 6:43:40 PM

>no one is vibe coding elixir

I did :) I made a browser-based MMO with Phoenix to test out liveview and learn the language: https://shopkeep.gg

And it was pretty annoying. Elixir doesn't really lend itself to vibe coding due to namespacing and aliasing of modules, pattern matching, all without static typing (I know, Dialyzer...). It also struggles to understand the difference between LiveComponents and LiveViews, where to send/handle messages between layers.

Without references to filenames, the agent perpetually decides "this doesn't exist, so I'll write it :)". I found it to be pretty challenging before figuring out I could force the agent to run `mix xref callers <Some.Module>` when trying to do cross-module refs.

(caveat: this was all with claude 3.5 sonnet)

by curiouser3

4/22/2025 at 6:42:33 PM

New frameworks don't align with vibe coding at all, because they are poorly represented in OpenAI, Anthropic & Google's datasets.

by doctorpangloss

4/22/2025 at 7:07:45 PM

Rust is an excellent vibe target because it won't compile unless it works. It may not do exactly what you think but that's what vibe testing is for.

by kelsey978126

4/22/2025 at 7:20:52 PM

I think the idea that "if Rust compiles then it works" is very untrue, especially for non-trivial software.

by sealeck

4/22/2025 at 6:52:52 PM

I vibe coded parts of https://gisformat.com/ backend in Rust in order to learn about Rust. So I think you are wrong there.

by sagolikasoppor

4/23/2025 at 3:49:36 AM

[dead]

by xyz_suspended

4/22/2025 at 3:34:49 PM

Oof this bit is rough!

> The startup supports Postgres, the most popular developer database system that’s an alternative to Google’s Firebase. Supabase’s goal: To be a one-stop backend for developers and "vibe coders."

by zefhous

4/22/2025 at 3:45:17 PM

Enabling more people to make cool things themselves isn't necessarily a bad thing.

by gkoberger

4/22/2025 at 3:50:58 PM

It's all fun and games until you realize the cool thing you made is locked into an overpriced cloud stack that will bleed you dry. "Vibe coders" seem to invariably end up offloading as much heavy lifting as possible to ultra-expensive PaaS/SaaS vendors, and those vendors are encouraging it (e.g. Vercel v0).

by jsheard

4/22/2025 at 3:55:06 PM

It's the right trade-off, IMO. Most projects won't succeed and the ones that do can be refactored - by real engineers if needed.

by jmathai

4/22/2025 at 4:55:57 PM

You make it sound like it’s a binary situation where in one case it doesn’t matter and in the other it’s No Problem. I think both are wrong.

An unsuccessful project might be unsuccessful because it got eaten by costs before it became successful.

A wildly successful project is risky to migrate.

by tobr

4/22/2025 at 5:03:11 PM

The YC crowd seems to think the only worthwhile businesses are worth $1 billion+ otherwise why bother

by tppiotrowski

4/22/2025 at 5:27:33 PM

I strongly disagree with this.

Most startups fail. Optimizing for getting revenue is more important than optimizing cost in the beginning.

If you get revenue you can solve the cost problem. If you don’t, it doesn’t matter.

Anything that gives you more shots at the goal is a win in a startup.

by slashdev

4/22/2025 at 5:09:36 PM

If you are trying to commercialize something, a popular project with bad margins is a better spot to be in than an unsuccessful project with good margins. If it's a personal learning project, that might not be the case.

by islewis

4/22/2025 at 5:23:51 PM

Counterexample:

https://x.com/levelsio/status/1730659933232730443

by tppiotrowski

4/22/2025 at 8:25:25 PM

I don’t think that’s a counter example. If hood maps shows a lot of potential then the $11k is something to figure out.

If not, then it’s poor price controls.

IIUC Pieter Levels talks a lot about not prematurely optimizing engineering solutions because most ideas will flop.

by jmathai

4/22/2025 at 5:30:07 PM

These cloud back and stacks are very cheap at low volume and honestly I expect them to remain so or even go down in price.

I've seen many colleagues bootstrap something - even if they're not themselves very technical - because they've leveraged these well integrated low cost platforms.

by intrasight

4/22/2025 at 8:22:04 PM

I do think it’s binary. The project either shows potential to meet your goal or it doesn’t.

I think it’s rare that fails to show potential because of the underlying technology that’s chosen.

Sure, Vercel is relatively expensive. But I just don’t see how you’d throw in the towel because the costs are too high without first evaluating how to lower them.

If you’re saying that the evaluation is likely to show that you’re stuck - I have never seen that be the case personally.

by jmathai

4/22/2025 at 4:27:42 PM

I’m a “real engineer” and I don’t want to do all that until I have to.

by jmtulloss

4/22/2025 at 4:47:52 PM

As a "real engineer" you'd likely use LLMs differently. I save my conversations, have chats and codebase exegesis summarized into .txt files, and constantly refactor LLM output. I have an increasingly reliable sense of when to dip in and write things myself and when to let the LLM rip. My LLM-assisted code is better than my hand-written code; how could it not be? I'd have to be committing raw LLM output without even reading it to end up somewhere worse. If I did that, how much of a "real engineer" would I be?

All this is to say: even if all progress on AI halted today, it would remain the case that, after the Internet, LLMs are the most impactful thing to happen to software development in my career. It would be weird if companies like Supabase weren't thinking about them in their product plans.

by tptacek

4/22/2025 at 7:24:39 PM

Have you found any good resources on how to get a good process going? That would be an interesting read.

I have two main issues, first the tooling is changing so rapidly that as I start to hone in on a process it changes out from under me. The second is verifying the output. I’m at like 90% success rate on getting code generated correctly (if not always faster than I could do it) but boy does that final 10% bite when I don’t notice.

An aside, I think the cloud ought to make your (perhaps especially your) list. At least for me that changed the whole economy of building new software enterprises.

by kasey_junk

4/22/2025 at 7:29:32 PM

Yeah I think it depends on what I’m doing.

For “real work” done by a “real engineer”, I approach it almost exactly as you say.

For side projects/personal software that I most likely would have never started pre-llms? I’ll just go full vibe code and see how far I get. Sometimes I have to just delete it, but sometimes it works. That’s cool.

by jmtulloss

4/22/2025 at 5:47:25 PM

Regarding refactor: My understanding is that vibes codebases are effectively write-only due to their structural incoherence.

by the__alchemist

4/22/2025 at 9:01:33 PM

That’s my understanding also. I think a project that’s vibe coded could easily be recreated by a programmer using coding assistance.

by jmathai

4/22/2025 at 4:07:09 PM

Agreed. And you can take a lot of the supabase code and try and host yourself if you get there.

by sroussey

4/22/2025 at 4:24:12 PM

I don’t think it happens because the “vibe coders” are necessarily clueless, it can very much be a calculated risk or tradeoff.

Based on the “vibe coders” crowd I see on X, they are a superset of indie hackers with lower barrier to entry when it comes to coding skills and less patience for mediocre success. They seem to have the “go big or go home” mindset.

As long as they have a popular product, they don’t mind forking over some of their profit to OpenAI or a hosting provider. None of the Ghibli generator app creators complained about paying OpenAI… If the product is not popular, no outrageous costs, and the product will be abandoned anyway very fast.

by serial_dev

4/22/2025 at 4:26:51 PM

> the cool thing you made is locked into an overpriced cloud stack that will bleed you dry

Not necessarily applicable to vibing with Supabase specifically, right?

There are several ways to host Supabase on your own computer, server, or cloud.

https://supabase.com/docs/guides/self-hosting

by adolph

4/22/2025 at 4:56:34 PM

PostgREST is open source, and so is the rest of Supabase.

Migrating from it is not that hard so far. I did it on an afternoon for a customer.

Also a couple friends are running the open source version in their own containers.

Maybe there are (or will be) cloud only features, but for the basic service there isn’t as much lock-in as something like AWS.

by whstl

4/22/2025 at 3:54:56 PM

Okay? Let's say it's $200/mo or something for a moderately popular app. An engineer starts at $200/hr, so you're still saving a ton.

With Vercel/Netlify, you're paying for ease of use. For a lot of people, that tradeoff is worth it. Not everything can be free.

by gkoberger

4/22/2025 at 5:24:30 PM

Is that 200 a made up number?

https://money.usnews.com/careers/best-jobs/computer-programm...

Do you have a better source for your number.

As far as cost, 200/month is nothing, but those are not the numbers we hear about when things spiral out of controll due to a ddos or sudden surge in popularity.

by mhitza

4/22/2025 at 5:39:20 PM

We serve thousands of customers off Supabase for $250/month including PITR. It’s a STEAL. Technical support is also responsive and knowledgeable. Outside of the auth SSR upgrade, it’s technically also been great to work with. Supabase is some of the best value we get from any vendor.

by anxman

4/22/2025 at 4:39:20 PM

Starts? With 40h/week, that's basically a $400k annual salary. This is certainly not the start price of an engineer.

by SomeoneOnTheWeb

4/22/2025 at 4:59:48 PM

If you hire someone full time, you can do the math that way.

But the market rate for a freelance midlevel US-based engineer would be about double per hour what you'd pay a full-time employee of the same level, to account for taxes/PTO/health care/etc.

by gkoberger

4/22/2025 at 5:18:20 PM

Would be happy to find something at half that, but there’s no work right now. Lots of ghost jobs and even upwork has twenty+ applicants fighting over $30/hr scraps.

by mixmastamyk

4/22/2025 at 4:32:47 PM

>An engineer starts at $200/hr

Starts?!

by inertiatic

4/22/2025 at 4:47:01 PM

I’m assuming that’s the fully burdened rate, i.e., salary, benefits, taxes, overhead, profit, etc that employees never see, even though they should.

I remember getting a sheet from an employer early in my career that fully broke down the cost of benefits and taxes and showed me the full cost of just my employment, not including overhead, profit, etc. it was rather eye opening because although I kid of knew it from accounting and finance, it never really impacted me quite as much before seeing the numbers.

by hoseyor

4/22/2025 at 5:06:45 PM

If the system didn't structure it that way, everyone would know the numbers and protest. As it is people pay up for the most part, they even defend the concept of taxing, supposedly going to public services.

by hirako2000

4/22/2025 at 5:49:30 PM

Heroku is the OG "vibe coding" platform and, honestly, it was awesome. The first platform where you could deploy with one CLI command, sure it was expensive, but for years it was my favorite place to prototype or MVP stuff.

by dvt

4/22/2025 at 5:40:56 PM

None of these are expensive if they help you ship products that solve problems that customers are willing to pay for.

by cpursley

4/22/2025 at 4:49:48 PM

I think the real "vibe coders" in the end will be people like me. Making neat little personal projects that don't use many resources and can be relatively insecure because they don't matter much. I made wannawatchsomething.com with no knowledge of how it works and full knowledge that it's insecure and dumb. It still does what I want and I couldn't have done it a year ago so it's a net win.

by cab11150904

4/22/2025 at 4:22:44 PM

Honestly I love that vercel and Superbase and these companies are making enormous amounts of money by only targeting JavaScript developers who have such a phobia of doing actual development work that they're willing to pay 10 times, 20 times the price for infrastructure to actually host their apps. They are not real developers and it's great to see them being squeezed and I'm glad that companies are making them pay through the nose and locking them in. They should suffer and face the consequences of their lack of skill.

by ilrwbwrkhv

4/22/2025 at 4:30:15 PM

“Real developer” label or not, it is now easier than ever to dream up, build, and ship an app. And at the end of the day, that’s all that matters—-what you ship. Just seems incredibly gatekeepy to devalue someone’s work based on the tools they used to build their product.

Yes, “vibecoding” still has issues (and likely will for the forseeable future). I’m sure the next decade will be an absolute boon for security researchers working with new companies. But you shouldn’t dismiss people based on their use of these tools.

And other commenters are right that these expensive infra tools can be replaced later when the idea has actually been validated.

by jim201

4/22/2025 at 4:25:59 PM

Let’s not raise ourselves up by saying that other developers are no true Scotsmen based on what language they prefer.

by mathgeek

4/22/2025 at 3:44:55 PM

I don't necessarily think this is a bad goal, but the term "vibe coder" is almost certainly considered derogatory now.

by rychco

4/22/2025 at 4:05:50 PM

The day before yesterday I got a technical assignment from a company I was interviewing with to build a Next.js app. Normally I would build it myself, but that day it just felt so tedious, so I gave Claude Code a try. To my surprise, with little to no guidance (probably cuz it was React), it built the app and it even looked very similar to mock-ups the company gave. I changed some things here and there and submitted the task. The whole thing was done in about half an hour. Yesterday they emailed me to schedule the next interview. I'm hooked.

by koakuma-chan

4/22/2025 at 4:10:24 PM

Sadly it seems the days of take home interview assignments are numbered. I much preferred them to live coding assessments when given the option.

by vrosas

4/22/2025 at 4:44:05 PM

We still do take-homes. You just design them assuming people are going to use LLMs. They're going to do that on the job anyways, so why tie a hand behind their back?

by tptacek

4/22/2025 at 5:00:34 PM

Same. We just ask people to explain what they delivered, and this is 1000x better and more interesting than any quiz or whiteboard.

by whstl

4/22/2025 at 5:04:51 PM

LLMs have also allowed us to significantly expand the scope of what we ask candidates to look at. Previously, we were constrained by time budgets (the candidate's, not ours) to a relatively small project, from which we had to read tea leaves; minor variations, objective but still small-bore, were determinative of how candidates ranked. Now we can drop a pretty ambitious project, which creates a lot of variation and room to demonstrate approach.

by tptacek

4/22/2025 at 4:12:57 PM

I turn 50 tomorrow and I love vibe coding. In the hands of an expert with decades of experience in all the internal corners of C, Python and Postgres I find AI tools to be miracles of technology. I know how to ask them exactly what I want and I know how to separate the goodness from the bullshit. If Supabase is bringing AI closer to the developer at the database level then that is a great thing.

by michelpp

4/22/2025 at 4:21:22 PM

Vibe coding is excellent if you have the experience to understand what the AI is churning out and then what to do with it.

The problem we have now is we have people who aren't engineers trying to make an app and they end up creating insecure and buggy messes, then struggle with figuring out how to deploy, or they end up destroying all their code with no recovery because they didn't know anything about version control.

by Sohcahtoa82

4/22/2025 at 5:01:57 PM

All of those things were already happening with normal developers 10, 20, 30 years ago, and will keep happening, with or without AI.

by whstl

4/23/2025 at 7:38:32 PM

AI allows it to happen at scale though.

by Sohcahtoa82

4/22/2025 at 4:44:37 PM

As a professional developer, this seems like a problem I don't need to care about.

by tptacek

4/22/2025 at 4:15:13 PM

Do you have any writings or materials that show your process in depth? I’m interested in learning from those who know how to really squeeze the juice out of these tools.

by dwaltrip

4/22/2025 at 4:43:10 PM

I think what they are saying is the 'secret sauce' to successfully vibe coding is being an expert with all the languages, frameworks and tools yourself.

Makes sense to me, vibe coding basically shifts your burden to specification and review, which are traditionally things a senior developer should be good at.

by sally_glance

4/22/2025 at 7:35:42 PM

I think there is a lot to be said about what tasks you give to it, how you describe the work and prompt it, and the iteration / workflow loop.

I have a limited intuition for this based off my AI usage the past few years, but I want to learn from the pros.

by dwaltrip

4/22/2025 at 5:43:14 PM

I agree with this - I hear a lot of hate towards vibe coding but my experience with voice dictation and using 20 years experience in the trenches and so being very specific telling the model what to do has been, well, refreshing to say the least.

I used to pride myself of knowing all the little ins and outs of the tech stack, especially when it comes to ops type stuff. This is still required, the difference is you don't need to spend 4 hours writing code - you can use the experience to get to the same result in 4 minutes.

I can see how "ask it for what you want and hope for the best" might not end well but personally - I am very much enjoying the process of distilling what I know we need to do next into a voice dictated prompt and then watching the AI just solve it based on what I said.

by binocarlos

4/23/2025 at 4:41:40 AM

Derogatory and just plain stupid.

by DidYaWipe

4/22/2025 at 4:50:36 PM

Only rough if you're pretentious.

Making it easy for engineers, experienced OR aspiring is huge.

by biznickman

4/22/2025 at 7:36:41 PM

Part of what I think is rough is the framing of Postgres being "an alternative to Google’s Firebase" in the article. I mean, ok yeah they are both databases in a sense, but they are not the same thing at all. Firebase is a service and Postgres a database technology, and certainly not well-described as an alternative to Firebase by anyone competent in the industry. Lol.

I don't mean to demean "vibe coders" exactly either, but rather jumping on the hype train of using that term for your funding pitch. You're using AI to learn to become a software developer? Great! No problem with that.

But also — if you now have a database involved and you're handling people's data, you better learn what you're doing. A database provider pushing "vibe coding" is not a good look imo.

by zefhous

4/22/2025 at 5:30:20 PM

Yeah the heroku model, arguably AI makes the barriers for aspiring coders lower which means more potential customers

by Rastonbury

4/22/2025 at 4:24:03 PM

Hey man, their money spends like anyone else's.

by bena

4/22/2025 at 3:36:03 PM

[flagged]

by enescakir

4/22/2025 at 4:59:29 PM

Are you implying that Postgres has bad docs?

by koakuma-chan

4/22/2025 at 3:50:09 PM

[flagged]

by tengbretson

4/22/2025 at 3:35:50 PM

[flagged]

by 9283409232

4/22/2025 at 3:36:53 PM

It's when an unskilled laborer sits down and asks the AI to write code, but as a business model.

by lionkor

4/22/2025 at 5:39:09 PM

It's a fun afternoon experiment. Grab some editor with free credits (I tried cursor) and ask the language model via chat to build the app. Accept all changes, check results, repeat.

Fully immersing myself to the vibe it took me somewhere between 1-2 hours to have the AI loop in an endless ~"i fixed the issue" message while I kept telling it that the thing is still broken.

Pretty fun when it works, but don't buy the hype that products are built exclusively with this strategy (though claims are out there that really like to make it seem so).

by mhitza

4/22/2025 at 4:32:20 PM

It lets someone write code rapidly they don't understand and can't check. As the saying goes, "debugging is at least twice as hard as writing something", so if you write something you barely understand, you CERTAINLY can't debug it when it breaks.

by pluto_modadic

4/22/2025 at 3:59:42 PM

Just let the AI code... don't worry about code bloat performance, security, data model, etc, just let it keep going and fixing the errors it makes.

by jppope

4/22/2025 at 4:30:12 PM

some trash that stupid people do

by dankobgd