I'm sure that a lot of the l33t h4x0rs here think that Supabase sucks and is only for amateurs but I'll say that as a former engineer who's getting back into building fun side projects again, Supabase has been incredible and just what I wanted. It's my favorite new product that I've started using in the last year. I hope they build out an enormous TAM of people who don't want to live inside a terminal and make a ton of money.
sebastiennight 6 hours ago [-]
I was looking for this comment.
A non-technical family member is working on a tech project, and giving them Lovable.dev with Supabase as a backend was like complete magic. No amount of fiddling with terminals or propping up postgres is too little.
We technical people always underestimate how fast things change when non-technical users can finally get things done without opening the hood.
asnyder 4 hours ago [-]
Back in the day we'd call this phase a design and workflow prototype as to not have to deal with all the technical components until the actual flow and concept is done.
Feels we're skipping these steps and "generating" prototypes that may or may not satisfy the need and moving forward with that code into final.
One of the huge benefits of things like Invision, Marvel, Avocode, Figma, etc. was to allow the idea and flow to truly get its legs and skip the days where devs would plop right into code and do 100s of iterations and updates in actual code. This was a huge gain in development and opened up roles for PMs and UI/UX, while keeping developer work more focused on the actual implementation.
Feels these generate design & code tools are regressing back to direct-Code prototypes without all that workflow and understanding of what should actually be happening BEFORE the code, and instead will return to the distractions of the "How", and its millions of iterations and updates, rather than "What".
Some of this was already unfortunately happening due to Figma's loss of focus on workflow and collaboration, but seems these AI generation tools have made many completely lose sight of what was nice about the improved workflow of planning, simply because we CAN now generate the things we think we want, doesn't mean we should, especially before we know what we actually want / need.
Maybe I'm just getting old, but that's my .02 :).
_zoltan_ 4 hours ago [-]
there is no need to this tedious, boring phase which you miss, especially since it still requires a significant of coding effort (eg to stitch a backend to figma).
you can vibe code a fully working UI+backend that requires way less effort so why bother with planning and iterating on the UI separately at all?
anybody who actually knows what they are doing gets 10x from these tools plus they enable non-coders to bring ideas to the market and do it fast.
asnyder 3 hours ago [-]
That's always been the justification to skip this phase :). Tools have just changed. One-person to small-team wonders that could code and build directly made the same arguments.
My point isn't to stitch things to Figma, that's abhorrent to me as well. My point is to not get bogged down on the implementation details, in this case an actually working DB, those tables, etc, but rather less fidelity actual full flow concepts that can be generated and iterated.
Then that can be fed into a magic genie GPT that generates the front-end, back-end, and all that good jazz.
namaria 29 minutes ago [-]
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.
biztos 1 hours ago [-]
Don’t get me wrong, I love Supabase, but
> you can vibe code a fully working UI+backend
…is gonna bring a lot of houses crashing down sooner or later.
joshstrange 44 minutes ago [-]
I couldn't agree more. "Vibe coding" is pretty cool, but it's not sustainable at least with with current technology. You're much better off being a knowledgeable developer who can guide an an LLM to write code for you.
One thing I will agree on though is that LLMs make it easier to iterate or try ideas and see if they'll work. I've been doing that a ton in my projects where I'll ask an LLM to build an interface and then if I like it I'll clean it up and or rebuild it myself.
I doubt that I'll ever use Figma to design, it's just too foreign to me. But LLMs let me work in a medium that I understand (code) while iterating quickly and trying ideas that I would never attempt because I wouldn't and be sure if they'd work out and it would take me a long time to implement them visually.
Really, that's where LLMs shine for me. Trying out an idea that you would even be capable of doing, but it would take you a long time. I can't tell you how many scripts I've asked ChatGPT or similar to write that I am fully capable of writing, but the return on investment just would not be there if I had to write it all by by hand. Additionally, I will use them to write scripts to debug problems or analyze logs/files. Again, things that I am perfectly capable of doing but would never do in the middle of a production issue because they would take too long and wouldn't necessarily yield results. With an LLM, I feel comfortable trying it out because at worst I'd burn a minute or two of of time and at best I can save myself hours. The return on investment just isn't there if it would take me 30 minutes to write that script and only then find out if it was useful or not.
namaria 27 minutes ago [-]
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.
itissid 2 hours ago [-]
This can only be true of some products. Often there are a lot of concerns like privacy, white labeling, legal consequences that need to be considered _before_ you vibe code.
giantrobot 5 hours ago [-]
> We technical people always underestimate how fast things change when non-technical users can finally get things done without opening the hood.
This is good and bad. Non-technical users throwing up a prototype quickly is good. Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad. It's easy for non-technical users to get a false sense of confidence if the thing they make looks good. This has been true since the RAD days of Delphi and VisualBasic.
sally_glance 5 hours ago [-]
Knowing the industry I'm pretty sure they will all push those AI prototypes to production - because they did the same with non-AI prototypes before. Now the question is once they inevitably pull in experienced folk for maintenance, refactoring and debugging, will it be easier or harder than working with that retired solo devs spaghetti codebase?
giantrobot 2 hours ago [-]
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.
namaria 21 minutes ago [-]
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.
yieldcrv 15 minutes ago [-]
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
sebastiennight 5 hours ago [-]
> Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad.
I beg to differ. Non-technical users pushing anything into production is GREAT!
For many, that's the only way they can get their internal tool done.
For many others, that's the only way they might get enough buyers and capital to hire a "real" developer to get rid of the security holes and non-obvious bugs.
I mean, it's not like every "senior developer" is immune from having obvious-in-retrospect security holes. Wasn't there a huge dating app recently with a glaring issue where you could list and access every photo and conversation ever shared, because nobody on their professional tech team secured the endpoints against enumeration of IDs?
somebehemoth 5 hours ago [-]
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.
_zoltan_ 4 hours ago [-]
let's not pretend that these apps collect anything so so secret and damning and private that it requires all this negativity around it.
it's just cybersecurity people fearing for their jobs :-)
sebastiennight 3 hours ago [-]
My feeling is that this is similar to saying, "non-professional AirBnB hosts are a terrible security nightmare, and the fact that people are not much safer in regulated hotels is no excuse to encourage even less security by encouraging novices to play in the hospitality business".
I agree with you on the downsides.
namaria 17 minutes ago [-]
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.
sfblah 6 minutes ago [-]
So you're saying it's something like an updated version of Yahoo Small Business?
highwaylights 4 hours ago [-]
Having worked with it quite a bit I'm still not sure I really understand what it is, which sounds like a bizarre sentence but:
It's Postgres, but bundled with some extensions and Postgrest. And a database UI. But hosted and it runs locally also by pulling the separate parts. Running it locally has issues though, so much so that I found it easier to run a docker compose of the separate parts from scratch and at that point just carry that through to a deployment, at which point is there still a reason to use Supabase rather than another hosted Postgres with the extensions?
It's a bit of a confusing product story.
jonplackett 2 hours ago [-]
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.
madeofpalk 4 hours ago [-]
it's just a firebase competitor, that's based on postgres and you can run sql against it if you want.
eddieroger 3 hours ago [-]
It's also implied, and proven by some, that having access to Postgres means you can up and leave Supabase if you want to later. It won't be snap-your-fingers easy, but it's more direct than other hosted SaaS where you can't access your data or the schemas.
swyx 24 minutes ago [-]
that "just" is carrying a lot of weight there
peab 3 hours ago [-]
exactly this
InstaPage 3 hours ago [-]
[dead]
csomar 3 hours ago [-]
You are not wrong that it’s a postgres + extensions. However, the tech market is very big now and that can sustain these valuations.
Realistically 99% of the users would still be screwed if they ever shut down, regardless of if it's open (see: Parse)... but it gives people a some confidence to hear they're building on a platform that they could (strictly in theory) spin up their own instance of should a similar rug pull ever occur
tough 3 hours ago [-]
They have also been giving back to postgres some of their extra work, and also their real time stuff i think is on erlang?
I agree you might prefer to choose the stack yourself, but for total n00bs and vibe coders supabase is a great start / boilerplate vs say the MEAN stack that was a hit 5y ago
whstl 5 hours ago [-]
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.
highwaylights 4 hours ago [-]
I like PostgREST for some of it's use cases (views mostly), but the issue I have with it is that I don't often want a user to have direct access to the database, even if it's limited to their own data.
Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail.
Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database.
Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.
whstl 3 hours ago [-]
> 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.
TSiege 4 hours ago [-]
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
whstl 3 hours ago [-]
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.
nawgz 3 hours ago [-]
> 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.
NewJazz 4 hours ago [-]
I have used them too, and I would say that at least for Hasura, performance can be poor for the generated queries. You have to be careful. Especially since they gate metrics behind their enterprise offering.
whstl 3 hours ago [-]
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.
2 hours ago [-]
mrcwinn 49 minutes ago [-]
Elite hacker here. Supabase is excellent.
digital_sawzall 5 hours ago [-]
How much are you paying per month?
spullara 2 hours ago [-]
It is really good for getting started but ultimately our companies transition off of it.
nprateem 3 hours ago [-]
It's all fun and games until you need caching - something that comes at unspecified cost from when I looked into it.
otterley 6 hours ago [-]
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!
candiddevmike 6 hours ago [-]
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...
clvx 6 hours ago [-]
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.
philomath_mn 5 hours ago [-]
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.
firtoz 4 hours ago [-]
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.
adamnemecek 6 hours ago [-]
> 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.
TechDebtDevin 6 hours ago [-]
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.
adamnemecek 5 hours ago [-]
The whole premise of cloud hosting businesses is that people don't want to manage stuff themselves.
hirako2000 5 hours ago [-]
They end up managing stuff themselves anyway. Plus managing another kind of bills.
adamnemecek 3 hours ago [-]
AWS seems to be doing fine.
BoorishBears 4 hours ago [-]
> 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.
diggan 6 hours ago [-]
> 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?
jsheard 6 hours ago [-]
> 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.
vecter 6 hours ago [-]
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.
hirako2000 5 hours ago [-]
Also reasons they need to go public. Growth is costly.
hashamali 6 hours ago [-]
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.
jsheard 6 hours ago [-]
Yeah I meant zero profit, poor wording on my part.
bombcar 6 hours ago [-]
The IPO is how (the shareholders) make money, by selling to bagholders.
jihadjihad 6 hours ago [-]
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.
mrweasel 3 hours ago [-]
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".
FloorEgg 5 hours ago [-]
Google bought firebase, so my guess is they are aiming for an Amazon or Microsoft acquisition.
fsndz 3 hours ago [-]
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
chasd00 1 hours ago [-]
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.
returnInfinity 6 hours ago [-]
They are definitely creating some value. Managed database.
colesantiago 6 hours ago [-]
> 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.
fakedang 6 hours ago [-]
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.
ZiiS 5 hours ago [-]
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.
fakedang 1 hours ago [-]
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.
carlhjerpe 5 hours ago [-]
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
fakedang 1 hours ago [-]
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.
tootie 4 hours ago [-]
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.
fakedang 1 hours ago [-]
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.
nikanj 4 hours ago [-]
The greater fool strategy has worked well for unprofitable tech companies for decades, and shows no signs of slowing down
9283409232 6 hours ago [-]
Acquisition. All of these VC companies raise unsustainable levels of money in hopes of acquisition or IPO. Supabase seems to be leaning towards acquisition.
doctorpangloss 3 hours ago [-]
> 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:
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.
carlhjerpe 6 hours ago [-]
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
ZiiS 5 hours ago [-]
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.
azemetre 1 hours ago [-]
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.
hfgjbcgjbvg 28 minutes ago [-]
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.
999900000999 6 hours ago [-]
>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).
NitpickLawyer 6 hours ago [-]
> 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).
999900000999 5 hours ago [-]
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.
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)
scosman 6 hours ago [-]
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.
teaearlgraycold 6 hours ago [-]
Yeah I’ve ran a small project where I just did everything with the “service account” credentials which operates like a normal Postgres connection.
balls187 6 hours ago [-]
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.
scosman 8 minutes ago [-]
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.
balls187 6 hours ago [-]
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)
groguzt 6 hours ago [-]
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.
TechDebtDevin 6 hours ago [-]
How is Djanjo a replacement for Supabase?
999900000999 5 hours ago [-]
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.
film42 6 hours ago [-]
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.
acrooks 5 hours ago [-]
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.
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.
siliconc0w 4 hours ago [-]
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'.
saxelsen 48 minutes ago [-]
$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.
dangoodmanUT 38 minutes ago [-]
where did you get 16M revenue?
crowcroft 3 hours ago [-]
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.
radicaldreamer 33 minutes ago [-]
Retool uses Supabase for its out of the box database setup
jameslk 6 hours ago [-]
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!
vrosas 6 hours ago [-]
Execs cashing out some of their shares to buy houses in Tahoe while the stock market is in the red.
codingwagie 6 hours ago [-]
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
xmorse 5 hours ago [-]
Both use AWS under the hood
codingwagie 5 hours ago [-]
point still stands
ru552 3 hours ago [-]
How are they giving AWS a run for their money when they use AWS for their own service? AWS profits from Supabase growth.
codingwagie 3 hours ago [-]
AWS is unusable in alot of cases.
5Qn8mNbc2FNCiVV 1 hours ago [-]
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
gabinator 6 hours ago [-]
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.
unhappy_meaning 1 hours ago [-]
And the decline of a good product begins because it will be all about profits for board members going forward...
constantlm 59 minutes ago [-]
To be fair this is a series D
zhoujianfu 6 hours ago [-]
I always felt like they’re the database dogman would use.
jedberg 2 hours ago [-]
As someone with a seven year old, I appreciated this. Thank you.
sophrocyne 5 hours ago [-]
Time to vibe code the data into "That supa awesome database over there"
jbs789 3 hours ago [-]
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…
Mortiffer 6 hours ago [-]
Why do they bring up vibe coding here. They are just a firebase alternative and Google has way superior ai code gen tools
justanotheratom 6 hours ago [-]
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.
6 hours ago [-]
lionkor 6 hours ago [-]
My guess is that they got that insane overvaluation because they sold themselves as an AI company
ru552 3 hours ago [-]
My humble guess is they sold themselves as the enabler for the AI vibe coding "revolution"
sailfast 41 minutes ago [-]
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.
zkmon 3 hours ago [-]
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.
joshdavham 2 hours ago [-]
> 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.
jordanmorgan10 5 hours ago [-]
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.
k2xl 6 hours ago [-]
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.
jamil7 6 hours ago [-]
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.
h1fra 5 hours ago [-]
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?
rozap 5 hours ago [-]
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.
ChadNauseam 1 hours ago [-]
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
nikanj 4 hours ago [-]
It's slow expensive postgres _with_AI_
6 hours ago [-]
6 hours ago [-]
desireco42 6 hours ago [-]
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.
janosch_123 6 hours ago [-]
Congrats to Anthony and the team! What an amazing milestone.
asim 5 hours ago [-]
Congratulations to anyone who can raise $200m, let alone have the VCs fly around the world to make it happen.
inside_story 6 hours ago [-]
please fix the drizzle- --> supabase integration.
6 hours ago [-]
sergiotapia 6 hours ago [-]
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?
rvz 6 hours ago [-]
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.
ru552 3 hours ago [-]
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.
peterldowns 3 hours ago [-]
FAL team is the real deal, they will absolutely not get acquired by any of these other "vibes" companies.
ilrwbwrkhv 5 hours ago [-]
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.
cab11150904 5 hours ago [-]
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?
hfgjbcgjbvg 4 hours ago [-]
The new age is back
wg0 5 hours ago [-]
Another heroku in the making. Also - where do these millions go? All into engineering?
factsaresacred 5 hours ago [-]
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.
While the funding is impressive, I haven’t come across too many people touting Supabase or using it in production.
brettnak 6 hours ago [-]
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.
murdockq 4 hours ago [-]
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.
xixixao 4 hours ago [-]
You should try Convex. It’s a better, higher level abstraction than Supabase.
atonse 6 hours ago [-]
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.
wyck 3 hours ago [-]
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.
herpdyderp 4 hours ago [-]
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.
slig 6 hours ago [-]
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.
xmorse 5 hours ago [-]
Imagine being a Postgres developer and getting 1% of that while being the core technology powering all these startups
tristan957 3 hours ago [-]
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.
daemonk 4 hours ago [-]
[flagged]
GuinansEyebrows 3 hours ago [-]
i dont want to listen to uninformed "AI-generated" music any more than i want to support uninformed "AI-generated" code
frankfrank13 4 hours ago [-]
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
curiouser3 3 hours ago [-]
>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)
kelsey978126 3 hours ago [-]
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.
sealeck 3 hours ago [-]
I think the idea that "if Rust compiles then it works" is very untrue, especially for non-trivial software.
doctorpangloss 3 hours ago [-]
New frameworks don't align with vibe coding at all, because they are poorly represented in OpenAI, Anthropic & Google's datasets.
jedberg 2 hours ago [-]
But you can just give them a prompt to teach them. Case in point, Transact has a prompt that you can put into an LLM that enables it to one-shot some simple programs:
I vibe coded parts of https://gisformat.com/ backend in Rust in order to learn about Rust. So I think you are wrong there.
2 hours ago [-]
zefhous 6 hours ago [-]
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."
gkoberger 6 hours ago [-]
Enabling more people to make cool things themselves isn't necessarily a bad thing.
jsheard 6 hours ago [-]
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).
jmathai 6 hours ago [-]
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.
tobr 5 hours ago [-]
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.
tppiotrowski 5 hours ago [-]
The YC crowd seems to think the only worthwhile businesses are worth $1 billion+ otherwise why bother
jmathai 2 hours ago [-]
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.
slashdev 4 hours ago [-]
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.
islewis 5 hours ago [-]
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.
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.
4 hours ago [-]
intrasight 4 hours ago [-]
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.
jmtulloss 5 hours ago [-]
I’m a “real engineer” and I don’t want to do all that until I have to.
tptacek 5 hours ago [-]
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.
kasey_junk 2 hours ago [-]
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.
jmtulloss 2 hours ago [-]
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.
the__alchemist 4 hours ago [-]
Regarding refactor: My understanding is that vibes codebases are effectively write-only due to their structural incoherence.
jmathai 52 minutes ago [-]
That’s my understanding also. I think a project that’s vibe coded could easily be recreated by a programmer using coding assistance.
sroussey 6 hours ago [-]
Agreed. And you can take a lot of the supabase code and try and host yourself if you get there.
serial_dev 5 hours ago [-]
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.
dvt 4 hours ago [-]
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.
whstl 5 hours ago [-]
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.
gkoberger 6 hours ago [-]
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.
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.
anxman 4 hours ago [-]
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.
SomeoneOnTheWeb 5 hours ago [-]
Starts? With 40h/week, that's basically a $400k annual salary. This is certainly not the start price of an engineer.
gkoberger 5 hours ago [-]
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.
mixmastamyk 5 hours ago [-]
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.
inertiatic 5 hours ago [-]
>An engineer starts at $200/hr
Starts?!
hoseyor 5 hours ago [-]
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.
hirako2000 5 hours ago [-]
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.
cpursley 4 hours ago [-]
None of these are expensive if they help you ship products that solve problems that customers are willing to pay for.
cab11150904 5 hours ago [-]
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.
adolph 5 hours ago [-]
> 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.
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.
jim201 5 hours ago [-]
“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.
mathgeek 5 hours ago [-]
Let’s not raise ourselves up by saying that other developers are no true Scotsmen based on what language they prefer.
6 hours ago [-]
rychco 6 hours ago [-]
I don't necessarily think this is a bad goal, but the term "vibe coder" is almost certainly considered derogatory now.
koakuma-chan 6 hours ago [-]
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.
vrosas 6 hours ago [-]
Sadly it seems the days of take home interview assignments are numbered. I much preferred them to live coding assessments when given the option.
tptacek 5 hours ago [-]
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?
whstl 5 hours ago [-]
Same. We just ask people to explain what they delivered, and this is 1000x better and more interesting than any quiz or whiteboard.
tptacek 5 hours ago [-]
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.
michelpp 6 hours ago [-]
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.
Sohcahtoa82 6 hours ago [-]
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.
whstl 5 hours ago [-]
All of those things were already happening with normal developers 10, 20, 30 years ago, and will keep happening, with or without AI.
tptacek 5 hours ago [-]
As a professional developer, this seems like a problem I don't need to care about.
dwaltrip 6 hours ago [-]
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.
sally_glance 5 hours ago [-]
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.
dwaltrip 2 hours ago [-]
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.
binocarlos 4 hours ago [-]
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.
biznickman 5 hours ago [-]
Only rough if you're pretentious.
Making it easy for engineers, experienced OR aspiring is huge.
zefhous 2 hours ago [-]
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.
Rastonbury 4 hours ago [-]
Yeah the heroku model, arguably AI makes the barriers for aspiring coders lower which means more potential customers
bena 5 hours ago [-]
Hey man, their money spends like anyone else's.
enescakir 6 hours ago [-]
[flagged]
2 hours ago [-]
koakuma-chan 5 hours ago [-]
Are you implying that Postgres has bad docs?
9283409232 6 hours ago [-]
[flagged]
2 hours ago [-]
lionkor 6 hours ago [-]
It's when an unskilled laborer sits down and asks the AI to write code, but as a business model.
mhitza 4 hours ago [-]
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).
pluto_modadic 5 hours ago [-]
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.
jppope 6 hours ago [-]
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.
dankobgd 5 hours ago [-]
some trash that stupid people do
tengbretson 6 hours ago [-]
[flagged]
2 hours ago [-]
ilrwbwrkhv 6 hours ago [-]
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.
fasbiner 4 hours ago [-]
> 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.
ilrwbwrkhv 4 hours ago [-]
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.
Rendered at 21:53:30 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Feels we're skipping these steps and "generating" prototypes that may or may not satisfy the need and moving forward with that code into final.
One of the huge benefits of things like Invision, Marvel, Avocode, Figma, etc. was to allow the idea and flow to truly get its legs and skip the days where devs would plop right into code and do 100s of iterations and updates in actual code. This was a huge gain in development and opened up roles for PMs and UI/UX, while keeping developer work more focused on the actual implementation.
Feels these generate design & code tools are regressing back to direct-Code prototypes without all that workflow and understanding of what should actually be happening BEFORE the code, and instead will return to the distractions of the "How", and its millions of iterations and updates, rather than "What".
Some of this was already unfortunately happening due to Figma's loss of focus on workflow and collaboration, but seems these AI generation tools have made many completely lose sight of what was nice about the improved workflow of planning, simply because we CAN now generate the things we think we want, doesn't mean we should, especially before we know what we actually want / need.
Maybe I'm just getting old, but that's my .02 :).
you can vibe code a fully working UI+backend that requires way less effort so why bother with planning and iterating on the UI separately at all?
anybody who actually knows what they are doing gets 10x from these tools plus they enable non-coders to bring ideas to the market and do it fast.
My point isn't to stitch things to Figma, that's abhorrent to me as well. My point is to not get bogged down on the implementation details, in this case an actually working DB, those tables, etc, but rather less fidelity actual full flow concepts that can be generated and iterated.
Then that can be fed into a magic genie GPT that generates the front-end, back-end, and all that good jazz.
The thing is, the cost of producing websites is already pretty low, but the value of websites mostly derives from network effects. So a rising flood of micro crud saas products will not be likely to generate much added value. And since interoperability will drive complexity, and transformer based LLMs are inherently limited at compositional tasks, any unforeseen value tapped by these extra websites will likely be offset by the maintainability and security breaks I mentioned. And because there is a delay in this signal, there is likely to be a bullwhip effect: an explosion of sites now and a burnout in a couple of years in which a lot of people will get severely turned off by the whole experience.
> you can vibe code a fully working UI+backend
…is gonna bring a lot of houses crashing down sooner or later.
One thing I will agree on though is that LLMs make it easier to iterate or try ideas and see if they'll work. I've been doing that a ton in my projects where I'll ask an LLM to build an interface and then if I like it I'll clean it up and or rebuild it myself.
I doubt that I'll ever use Figma to design, it's just too foreign to me. But LLMs let me work in a medium that I understand (code) while iterating quickly and trying ideas that I would never attempt because I wouldn't and be sure if they'd work out and it would take me a long time to implement them visually.
Really, that's where LLMs shine for me. Trying out an idea that you would even be capable of doing, but it would take you a long time. I can't tell you how many scripts I've asked ChatGPT or similar to write that I am fully capable of writing, but the return on investment just would not be there if I had to write it all by by hand. Additionally, I will use them to write scripts to debug problems or analyze logs/files. Again, things that I am perfectly capable of doing but would never do in the middle of a production issue because they would take too long and wouldn't necessarily yield results. With an LLM, I feel comfortable trying it out because at worst I'd burn a minute or two of of time and at best I can save myself hours. The return on investment just isn't there if it would take me 30 minutes to write that script and only then find out if it was useful or not.
This is good and bad. Non-technical users throwing up a prototype quickly is good. Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad. It's easy for non-technical users to get a false sense of confidence if the thing they make looks good. This has been true since the RAD days of Delphi and VisualBasic.
I think there's going to be the same problems as there are fixing bad body shop code. The companies that pushed their "vibe code" for a few dollars worth of AI tokens will expect people to work for pennies and/or have unreasonable time demands. There's also no ability to interview the original authors to figure out what they were thinking.
Meanwhile their customers are getting screwed over with data leaks if not outright hacks (depending on the app).
It's not a whole new issue, shitty contractors have existed for decades, but AI is pushing down the value of actual expertise.
For nearly 50 years now, software causes disruption, demand drives labor costs, enterprise responds with some silver bullet, haircuts in expensive suits collect bonuses, their masters pocket capital gains, and the chicken come home to roost with a cycle of disruption and labor cost increases. LLMs are being sold as disruption but it's actually another generation of enterprise tech. Hence the confusion. Vibe coding is just PR. Karpathy knows what he's doing.
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
I beg to differ. Non-technical users pushing anything into production is GREAT!
For many, that's the only way they can get their internal tool done.
For many others, that's the only way they might get enough buyers and capital to hire a "real" developer to get rid of the security holes and non-obvious bugs.
I mean, it's not like every "senior developer" is immune from having obvious-in-retrospect security holes. Wasn't there a huge dating app recently with a glaring issue where you could list and access every photo and conversation ever shared, because nobody on their professional tech team secured the endpoints against enumeration of IDs?
I agree it is great that more people can build software, but let's not pretend there are zero downsides.
it's just cybersecurity people fearing for their jobs :-)
I agree with you on the downsides.
There was a reason the industry was regulated, and circumventing these reasons with an app has been a net negative to society.
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.
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.
Realistically 99% of the users would still be screwed if they ever shut down, regardless of if it's open (see: Parse)... but it gives people a some confidence to hear they're building on a platform that they could (strictly in theory) spin up their own instance of should a similar rug pull ever occur
I agree you might prefer to choose the stack yourself, but for total n00bs and vibe coders supabase is a great start / boilerplate vs say the MEAN stack that was a hit 5y ago
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.
Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail.
Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database.
Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.
Congratulations: that's not basic CRUD anymore, so you ran into the 5% of cases not covered by an automatic CRUD API.
And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time.
You don't have to throw the baby away with the bathwater just because it doesn't cover 5% of cases the way you want.
It's a rite of passage to realize that "use the right tool for the job" means you can use two tools at the same time for the same project. There are nails and screws. You can use a hammer and a screwdriver at the same time.
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
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.
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.
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!
They also offer so much more than just postgres. Though I use them only for postgres myself.
Supabase defo has a much higher mindshare.
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.
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?
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.
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".
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.
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
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)
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).
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).
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...
But if you usecase involves Supabase auth, using a service account to bypass RLS is kind of like hardcoding connection strings.
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.
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.
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
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.
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.
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.
Nevertheless congrats to the Supabase team!
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
And I believe both Supabase and Vercel run all their services on AWS anyways, so AWS gets paid no matter what.
I've always taken issue with branding Supabase as an alternative to Firebase. Firebase is a PaaS whereas Supabase is more of a BaaS.
"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.
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.
I don't think this is a good sign.
When I see valuations like this, they are overvalued until they use that money to acquire another company for a total addressable market expansion.
Google were late to the game but they've built perhaps one of the easiest cloud platforms to work with.
While the funding is impressive, I haven’t come across too many people touting Supabase or using it in production.
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.
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.
1. oxc (oxlint)
2. vercel
3. fly.io
probably more! and more every day
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)
https://github.com/dbos-inc/dbos-docs/blob/main/docs/python/...
> 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."
An unsuccessful project might be unsuccessful because it got eaten by costs before it became successful.
A wildly successful project is risky to migrate.
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.
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.
https://x.com/levelsio/status/1730659933232730443
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Starts?!
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.
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
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.
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.
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.
I have a limited intuition for this based off my AI usage the past few years, but I want to learn from the pros.
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.
Making it easy for engineers, experienced OR aspiring is huge.
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.
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).
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.
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.