[HN Gopher] Supabase raises $200M Series D at $2B valuation
___________________________________________________________________
Supabase raises $200M Series D at $2B valuation
Author : baristaGeek
Score : 265 points
Date : 2025-04-22 15:17 UTC (7 hours ago)
(HTM) web link (finance.yahoo.com)
(TXT) w3m dump (finance.yahoo.com)
| otterley wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| adamnemecek wrote:
| > 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 wrote:
| 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 wrote:
| The whole premise of cloud hosting businesses is that
| people don't want to manage stuff themselves.
| hirako2000 wrote:
| They end up managing stuff themselves anyway. Plus
| managing another kind of bills.
| adamnemecek wrote:
| AWS seems to be doing fine.
| firtoz wrote:
| 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.
| BoorishBears wrote:
| > 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.
| tschellenbach wrote:
| it's an aggressive preemptive round, so i'd guess 2b/50 = 40M
| of revenue. Probably low margins since the free tier/ hosting
| postgres nature of the business.
| colesantiago wrote:
| > 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 wrote:
| 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.
| carlhjerpe wrote:
| 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 wrote:
| 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.
| ZiiS wrote:
| 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 wrote:
| 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.
| tootie wrote:
| 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 wrote:
| 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.
| diggan wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| Also reasons they need to go public. Growth is costly.
| bombcar wrote:
| The IPO is how (the shareholders) make money, by selling to
| bagholders.
| hashamali wrote:
| 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 wrote:
| Yeah I meant zero profit, poor wording on my part.
| jihadjihad wrote:
| 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.
| lionkor wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| returnInfinity wrote:
| They are definitely creating some value. Managed database.
| 9283409232 wrote:
| Acquisition. All of these VC companies raise unsustainable
| levels of money in hopes of acquisition or IPO. Supabase seems
| to be leaning towards acquisition.
| FloorEgg wrote:
| Google bought firebase, so my guess is they are aiming for an
| Amazon or Microsoft acquisition.
| nikanj wrote:
| The greater fool strategy has worked well for unprofitable tech
| companies for decades, and shows no signs of slowing down
| doctorpangloss wrote:
| > Are they sustainable long term as a standalone business?
|
| Was Meteor? They are _exactly_ the same thing. And I really
| liked Meteor!
|
| To me, the more money pouring in, the better. That said:
|
| https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRCVKYR...
|
| (The Silicon Valley Economy cartoon)
| fsndz wrote:
| 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 wrote:
| 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.
| mrweasel wrote:
| 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".
| zhoujianfu wrote:
| I always felt like they're the database dogman would use.
| sophrocyne wrote:
| Time to vibe code the data into "That supa awesome database
| over there"
| jedberg wrote:
| As someone with a seven year old, I appreciated this. Thank
| you.
| film42 wrote:
| 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.
| candiddevmike wrote:
| Their series C was in September 2024!
| acrooks wrote:
| Their 2024 revenue was estimated at $16.8M [1] and $10.5M in
| 2023. If you extrapolate that growth rate +1 year you can
| assume it's now $26.9M. Another source estimates it at $15M in
| 2025 [2].
|
| So if you assume their revenue is in that range, you're looking
| at 66x to 133x ARR multiple. In today's market that's quite a
| big markup. Standard SaaS right now is probably more like
| 5-15x. AI is a lot more (but Supabase isn't AI). But they are a
| key leader in their market, so probably get a meaningful bonus
| for that. And I'm sure a lot of big industry investors were
| competing against each other for the Supabase deal, so that
| definitely would have helped valuation too. Also, at their
| maturity today, they are probably showing some great success
| signing big enterprise deals and telling a story about how that
| will grow.
|
| That being said, those factors alone don't answer 66-133x.
| Perhaps Supabase's strongest angle is their opportunity for
| product-led growth:
|
| - They have a huge number of people on a free tier
|
| - The growth rate of free tier users might be accelerating
|
| - The conversion rate of free tier users to paid users might
| also be increasing
|
| - They're adding more things that people can pay for,
| increasing LTV of customers. e.g., for my business, we probably
| 20x our Supabase cost in the last 6 months - most of that is
| due to our growth but also there are a lot of things we can buy
| from Supabase beyond compute.
|
| So I would assume, in addition to the above, they're telling a
| story about their actual revenue growth rate will accelerate
| meaningfully because of all of these factors working together.
|
| Lots of assumptions in here, but you can start to see how a lot
| of different factors + a hype multiple could lead to such a
| valuation.
|
| [1] https://getlatka.com/companies/supabase.com#revenue
|
| [2] https://leadiq.com/c/supabase/5ed1e4778a998f161ef62998
| Mortiffer wrote:
| Why do they bring up vibe coding here. They are just a firebase
| alternative and Google has way superior ai code gen tools
| lionkor wrote:
| My guess is that they got that insane overvaluation because
| they sold themselves as an AI company
| ru552 wrote:
| My humble guess is they sold themselves as the enabler for
| the AI vibe coding "revolution"
| justanotheratom wrote:
| 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.
| zefhous wrote:
| 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."
| rychco wrote:
| I don't necessarily think this is a bad goal, but the term
| "vibe coder" is almost certainly considered derogatory now.
| koakuma-chan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Same. We just ask people to explain what they delivered,
| and this is 1000x better and more interesting than any
| quiz or whiteboard.
| tptacek wrote:
| 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 wrote:
| 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.
| dwaltrip wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Sohcahtoa82 wrote:
| 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.
| tptacek wrote:
| As a professional developer, this seems like a problem I
| don't need to care about.
| whstl wrote:
| All of those things were already happening with normal
| developers 10, 20, 30 years ago, and will keep happening,
| with or without AI.
| binocarlos wrote:
| 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.
| gkoberger wrote:
| Enabling more people to make cool things themselves isn't
| necessarily a bad thing.
| jsheard wrote:
| 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).
| gkoberger wrote:
| 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.
| inertiatic wrote:
| >An engineer starts at $200/hr
|
| Starts?!
| hoseyor wrote:
| 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 wrote:
| 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.
| SomeoneOnTheWeb wrote:
| Starts? With 40h/week, that's basically a $400k annual
| salary. This is certainly not the _start_ price of an
| engineer.
| gkoberger wrote:
| 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 wrote:
| 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.
| mhitza wrote:
| Is that 200 a made up number?
|
| https://money.usnews.com/careers/best-jobs/computer-
| programm...
|
| Do you have a better source for your number.
|
| As far as cost, 200/month is nothing, but those are not
| the numbers we hear about when things spiral out of
| controll due to a ddos or sudden surge in popularity.
| anxman wrote:
| 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.
| jmathai wrote:
| 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.
| sroussey wrote:
| Agreed. And you can take a lot of the supabase code and
| try and host yourself _if_ you get there.
| jmtulloss wrote:
| I'm a "real engineer" and I don't want to do all that
| until I have to.
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tobr wrote:
| 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 wrote:
| The YC crowd seems to think the only worthwhile
| businesses are worth $1 billion+ otherwise why bother
| islewis wrote:
| 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.
| tppiotrowski wrote:
| Counterexample:
|
| https://x.com/levelsio/status/1730659933232730443
| jmathai wrote:
| 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.
| slashdev wrote:
| 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.
| intrasight wrote:
| 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.
| jmathai wrote:
| 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.
| the__alchemist wrote:
| Regarding refactor: My understanding is that vibes
| codebases are effectively write-only due to their
| structural incoherence.
| jmathai wrote:
| That's my understanding also. I think a project that's
| vibe coded could easily be recreated by a programmer
| using coding assistance.
| ilrwbwrkhv wrote:
| 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.
| mathgeek wrote:
| Let's not raise ourselves up by saying that other
| developers are no true Scotsmen based on what language
| they prefer.
| jim201 wrote:
| "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.
| serial_dev wrote:
| 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.
| adolph wrote:
| > the cool thing you made is locked into an overpriced
| cloud stack that will bleed you dry
|
| Not necessarily applicable to vibing with Supabase
| specifically, right?
|
| _There are several ways to host Supabase on your own
| computer, server, or cloud._
|
| https://supabase.com/docs/guides/self-hosting
| cab11150904 wrote:
| 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.
| whstl wrote:
| 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.
| cpursley wrote:
| None of these are expensive if they help you ship products
| that solve problems that customers are willing to pay for.
| dvt wrote:
| 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.
| bena wrote:
| Hey man, their money spends like anyone else's.
| biznickman wrote:
| Only rough if you're pretentious.
|
| Making it easy for engineers, experienced OR aspiring is huge.
| Rastonbury wrote:
| Yeah the heroku model, arguably AI makes the barriers for
| aspiring coders lower which means more potential customers
| zefhous wrote:
| 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.
| janosch_123 wrote:
| Congrats to Anthony and the team! What an amazing milestone.
| jameslk wrote:
| 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 wrote:
| Execs cashing out some of their shares to buy houses in Tahoe
| while the stock market is in the red.
| hackitup7 wrote:
| 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 wrote:
| 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.
| giantrobot wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sebastiennight wrote:
| > 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 wrote:
| 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.
| sebastiennight wrote:
| 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 wrote:
| 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.
| conductr wrote:
| This is a contrived situation. Most of the apps in
| discussion see little to no use and go dead soon after
| launch. The vast majority are collecting little data of
| negligible risk.
|
| If a user is confident enough about a no name company
| that they give them enough info to make identity theft a
| possibility, it was only a matter of time before a
| spammer/phishing attack gets them anyway
| yieldcrv wrote:
| 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
| asnyder wrote:
| 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_ wrote:
| 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 wrote:
| 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 wrote:
| 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.
| itissid wrote:
| 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.
| biztos wrote:
| 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 wrote:
| 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 wrote:
| 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.
| digital_sawzall wrote:
| How much are you paying per month?
| whstl wrote:
| 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.
| NewJazz wrote:
| 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 wrote:
| 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.
| TSiege wrote:
| 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
| nawgz wrote:
| > As engineer #2 it's a mess
|
| As a long-time Hasura stan, I can't agree with this in any
| way.
|
| > Your entire schema is exposed
|
| In what sense? All queries to the DB go thru Hasura's API,
| there is no direct DB access. Roles are incredibly easy to
| set up and limit access on. Auth is easy to configure.
|
| If you're really upset about this direct access, you can
| just hide the GQL endpoint and put REST endpoints that
| execute GQL queries in front of Hasura.
|
| > Business logic gets pushed into your front end because
| where else do you run it unless you make an API wrapper
|
| > Likewise you can't easily customize your API without
| building an API on top of your API. You're doing weird
| extra network hops
|
| ... How is an API that queries Hasura via GQL any different
| than an API that queries PG via SQL? Put your business
| logic in an API. Separating direct data access from API
| endpoints is a long-since solved problem.
|
| Colocating Hasura and PG or Hasura and your API makes these
| network hops trivial.
|
| Since Hasura also manages roles and access control, these
| "extra hops" are big value adds.
|
| > You're pushed into fake open source where you can't
| always run the software independently
|
| ... Are you implying they will scrub the internet of their
| docker images? I always self-host Hasura. Have for years.
|
| > I think the people who write this off as "backend
| engineers feel threatened" aren't taking the time to
| understand the arguments they're hearing
|
| I think your arguments pretty much sum up why people think
| it's just about backend engineers feeling threatened - your
| sole point with any merit is that there's one extra network
| leg, but in a microservices world that's generally
| completely inconsequential.
| whstl wrote:
| I completely disagree.
|
| Backends are far messier (especially when built over time
| by a team), more expensive and less flexible than a GraphQL
| or PostgREST's api.
|
| _> I 've only worked with Hasura, but I can say it's an
| insecure nightmare that forces anti-patterns_
|
| Writing backend code without knowing what you're doing is
| also an insecure nightmare that forces anti-patterns. All
| good engineering practices still need to apply to Hasura.
|
| Nothing says that "everything must go through it". Use it
| for the parts it fits well, use a normal backend for the
| non-CRUD parts. This makes securing tables easier for both
| Hasura and PostgREST.
|
| _> Business logic gets pushed into your front end because
| where else do you run it unless you make an API wrapper.
| You 're doing weird extra network hops if you have other
| services that need the data but can't safely access it
| directly_
|
| I'm gonna disagree a bit with the sibling post here. If you
| think that going through Hasura for everything is not
| working: just don't.
|
| This is 100% a self-imposed limitation. Hasura and
| PostgREST still allow you to have a separate backend that
| goes around it. There is nothing forbidding you from
| accessing the DB directly from another backend. This is not
| different from accessing the same database from two
| different classes. Keep the 100% CRUD part on
| Hasura/PostgREST, keep the fiddly bits in the backend.
|
| The kind of dogma that says that everything must be built
| with those tools produces _worse_ apps. You 're describing
| it yourself.
|
| _> I think the people who write this off as "backend
| engineers feel threatened" aren't taking the time to
| understand the arguments they're hearing_
|
| I have heard the arguments and all I hear is people
| complaining about how hard it is to shove round pieces in
| square holes. These tools can be used correctly, but just
| like anything else they have a soft spot that you have to
| learn.
|
| Once again: "use right tool for the job" doesn't mean you
| can only use a single tool in your project.
| LinXitoW wrote:
| I've only played with these kinds of plug and play
| databases, but mixing and matching seems like the worst
| of both worlds. The plug and play is gone, because some
| things might me in API 1, some others in API 2, and maybe
| worst of all, their domains might overlap. So you need to
| know that the "boring" changes happen via the postgREST,
| but the fancier ones via some custom API. The APIs will
| probably also drift apart in small ways, making
| everything even more error prone.
| highwaylights wrote:
| 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 wrote:
| _> Now I need to send a confirmation e-mail to make sure
| the e-mail is valid, but at this point I can 't protect the
| integrity of the database with RLS because the
| e-mail/receipt/confirm loop lives outside the database
| entirely_
|
| Congratulations: that's not basic CRUD anymore, so you ran
| into the 5% of cases not covered by an automatic CRUD API.
|
| And I don't see what's the dilemma here. Just use a normal
| endpoint. Keep using PostgREST to save time.
|
| You don't have to throw the baby away with the bathwater
| just because it doesn't cover 5% of cases the way you want.
|
| It's a rite of passage to realize that "use the right tool
| for the job" means you can use two tools at the same time
| for the same project. There are nails and screws. You can
| use a hammer and a screwdriver at the same time.
| no_wizard wrote:
| >You can use a hammer and a screwdriver at the same time
|
| How do you balance the nail and screw? I'm serious, I'm
| trying to picture this, hammer in one hand, screwdriver
| in the other, and the problem I see here is the nail and
| screw need to be set first, which implies I can't
| completely use them both at the same time.
|
| Perhaps my brain is too literal here, but I can't figure
| how to do this without starting with one or the other
| first
| highwaylights wrote:
| 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.
| madeofpalk wrote:
| it's just a firebase competitor, that's based on postgres and
| you can run sql against it if you want.
| peab wrote:
| exactly this
| eddieroger wrote:
| 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 wrote:
| that "just" is carrying a lot of weight there
| BoorishBears wrote:
| Not really a confusing story: it's a PaaS that wants to beat
| fears of becoming another Parse
| (https://www.willowtreeapps.com/craft/parse-shutdown-what-
| it-...)
|
| Realistically 99% of the users would still be screwed if they
| ever shut down, regardless of if it's open (see: Parse)...
| but it gives people a some confidence to hear they're
| building on a platform that they could (strictly in theory)
| spin up their own instance of should a similar rug pull ever
| occur
| tough wrote:
| 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
| csomar wrote:
| You are not wrong that it's a postgres + extensions. However,
| the tech market is _very_ big now and that can sustain these
| valuations.
| jonplackett wrote:
| 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.
| nprateem wrote:
| It's all fun and games until you need caching - something that
| comes at unspecified cost from when I looked into it.
| spullara wrote:
| It is really good for getting started but ultimately our
| companies transition off of it.
| mrcwinn wrote:
| Elite hacker here. Supabase is excellent.
| isaachinman wrote:
| Not until/unless it has proper offline-first support. Check
| out InstantDB and Triplit.
| sfblah wrote:
| So you're saying it's something like an updated version of
| Yahoo Small Business?
| j45 wrote:
| World still needs a replacement for Microsoft Access on the
| web.
|
| It's been so long that new ideas are solving parts on the
| access spectrum without seemingly being aware of it.
|
| Supabase and others would have a smaller footprint to add an
| app layer and reporting layer to their tool since it is data as
| the cornerstone not an afterthought
| k2xl wrote:
| 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 wrote:
| 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.
| cpursley wrote:
| > just a few thousand users was $70 last month.
|
| Few Thousand!?! Sound very reasonable to me. Monetize just two
| of those users at $35 per month and your server costs are
| covered. Or run it yourself, there's a lot of moving parts but
| it's all open source.
| rvz wrote:
| 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.
| ilrwbwrkhv wrote:
| 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 wrote:
| 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?
| ru552 wrote:
| 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 wrote:
| FAL team is the real deal, they will absolutely not get
| acquired by any of these other "vibes" companies.
| desireco42 wrote:
| 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.
| inside_story wrote:
| please fix the drizzle- --> supabase integration.
| cpursley wrote:
| What's even the point of using drizzle with supabase? Isn't the
| entire point of supabase PostgREST and convenience tooling
| around it?
| kaladin_1 wrote:
| Congrats team!
|
| I was a speaker in a local Supabase event just few weeks ago,
| https://shorturl.at/JwWMk. We had a local event in Abuja,
| Nigeria. There we promoted their Launch Week 14 series,
| highlighting new features from Supabase. In reality, it became an
| event to show people how to bootstrap a quick backend for their
| SME business in a weekend.
| awb wrote:
| A recent project on HN declared Supabase dead:
| https://www.isthistechdead.com/supabase
|
| While the funding is impressive, I haven't come across too many
| people touting Supabase or using it in production.
| atonse wrote:
| 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.
| herpdyderp wrote:
| 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.
| wyck wrote:
| 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.
| slig wrote:
| 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.
| brettnak wrote:
| 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 wrote:
| 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 wrote:
| You should try Convex. It's a better, higher level
| abstraction than Supabase.
| 999900000999 wrote:
| >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).
| scosman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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)
| NitpickLawyer wrote:
| > 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 wrote:
| Hosting it on an actual server with a URL is not a fun
| experience. You need to generate a specific type of string to
| get it to work.
|
| This isn't documented anywhere. Deep deep in their GitHub
| issues you'll find a script for generating this magic string
| which needs to be set as an environment variable.
|
| See https://github.com/supabase/supabase/issues/17164#issueco
| mme...
| Zekio wrote:
| 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)
| k4rli wrote:
| Sure "it's in the docs" but last time our devops tried
| the compose file with ~10 or so services it took several
| days of fiddling with all sorts of different issues. It
| is just not made for selfhosting at all. It can be so
| much simpler but JS devs like it different.
| groguzt wrote:
| 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 wrote:
| How is Djanjo a replacement for Supabase?
| 999900000999 wrote:
| 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.
| sergiotapia wrote:
| 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?
| ilrwbwrkhv wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| codingwagie wrote:
| 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
| gabinator wrote:
| 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.
| xmorse wrote:
| Both use AWS under the hood
| codingwagie wrote:
| point still stands
| ru552 wrote:
| How are they giving AWS a run for their money when they use
| AWS for their own service? AWS profits from Supabase
| growth.
| codingwagie wrote:
| AWS is unusable in alot of cases.
| 5Qn8mNbc2FNCiVV wrote:
| 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
| chipgap98 wrote:
| Right but they run on AWS. So AWS is making money every
| time someone uses Vercel or Supabase
| wg0 wrote:
| Another heroku in the making. Also - where do these millions go?
| All into engineering?
| xmorse wrote:
| Imagine being a Postgres developer and getting 1% of that while
| being the core technology powering all these startups
| tristan957 wrote:
| 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.
| h1fra wrote:
| 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 wrote:
| 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.
| nikanj wrote:
| It's slow expensive postgres _with_AI_
| ChadNauseam wrote:
| 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
| asim wrote:
| Congratulations to anyone who can raise $200m, let alone have the
| VCs fly around the world to make it happen.
| jordanmorgan10 wrote:
| 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.
| factsaresacred wrote:
| 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.
| bze12 wrote:
| Do you use firebase?
| daemonk wrote:
| [flagged]
| GuinansEyebrows wrote:
| i dont want to listen to uninformed "AI-generated" music any
| more than i want to support uninformed "AI-generated" code
| daemonk wrote:
| Sure. But it's not really about you. I wouldn't break into
| someone's house and tell them they painted their house an
| uninformed color.
|
| If something sucks or won't scale, it will sort itself out in
| the market.
| hfgjbcgjbvg wrote:
| The new age is back
| frankfrank13 wrote:
| 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
| doctorpangloss wrote:
| New frameworks don't align with vibe coding at all, because
| they are poorly represented in OpenAI, Anthropic & Google's
| datasets.
| jedberg wrote:
| 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:
|
| https://github.com/dbos-inc/dbos-
| docs/blob/main/docs/python/...
| curiouser3 wrote:
| >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)
| sagolikasoppor wrote:
| I vibe coded parts of https://gisformat.com/ backend in Rust in
| order to learn about Rust. So I think you are wrong there.
| kelsey978126 wrote:
| 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 wrote:
| I think the idea that "if Rust compiles then it works" is
| very untrue, especially for non-trivial software.
| siliconc0w wrote:
| 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'.
| zkmon wrote:
| 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.
| jbs789 wrote:
| 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...
| crowcroft wrote:
| 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.
| joshdavham wrote:
| > 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.
| chaosprint wrote:
| can you explain more?
| unhappy_meaning wrote:
| And the decline of a good product begins because it will be all
| about profits for board members going forward...
| constantlm wrote:
| To be fair this is a series D
| saxelsen wrote:
| $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 wrote:
| where did you get 16M revenue?
| sailfast wrote:
| 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.
| radicaldreamer wrote:
| Retool uses Supabase for its out of the box database setup
| hfgjbcgjbvg wrote:
| 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.
| socketcluster wrote:
| I built a 'serverless' platform that's similar, smaller but more
| focus on low-code than Supabase https://saasufy.com/
|
| All the components are declarative HTML and update in realtime.
| Similar concept as HTMX but doesn't require any backend code. You
| can still implement complex UX, authentication, access control
| and filtered views (indexing and all).
|
| I built this app with it over a few months as a weekend project:
| https://www.insnare.net/app/#/onboarding/country/All
___________________________________________________________________
(page generated 2025-04-22 23:00 UTC)