Supabase raises $200M Series D at $2B valuation
221 comments
·April 22, 2025hackitup7
sebastiennight
I was looking for this comment.
A non-technical family member is working on a tech project, and giving them Lovable.dev with Supabase as a backend was like complete magic. No amount of fiddling with terminals or propping up postgres is too little.
We technical people always underestimate how fast things change when non-technical users can finally get things done without opening the hood.
asnyder
Back in the day we'd call this phase a design and workflow prototype as to not have to deal with all the technical components until the actual flow and concept is done.
Feels we're skipping these steps and "generating" prototypes that may or may not satisfy the need and moving forward with that code into final.
One of the huge benefits of things like Invision, Marvel, Avocode, Figma, etc. was to allow the idea and flow to truly get its legs and skip the days where devs would plop right into code and do 100s of iterations and updates in actual code. This was a huge gain in development and opened up roles for PMs and UI/UX, while keeping developer work more focused on the actual implementation.
Feels these generate design & code tools are regressing back to direct-Code prototypes without all that workflow and understanding of what should actually be happening BEFORE the code, and instead will return to the distractions of the "How", and its millions of iterations and updates, rather than "What".
Some of this was already unfortunately happening due to Figma's loss of focus on workflow and collaboration, but seems these AI generation tools have made many completely lose sight of what was nice about the improved workflow of planning, simply because we CAN now generate the things we think we want, doesn't mean we should, especially before we know what we actually want / need.
Maybe I'm just getting old, but that's my .02 :).
_zoltan_
there is no need to this tedious, boring phase which you miss, especially since it still requires a significant of coding effort (eg to stitch a backend to figma).
you can vibe code a fully working UI+backend that requires way less effort so why bother with planning and iterating on the UI separately at all?
anybody who actually knows what they are doing gets 10x from these tools plus they enable non-coders to bring ideas to the market and do it fast.
giantrobot
> We technical people always underestimate how fast things change when non-technical users can finally get things done without opening the hood.
This is good and bad. Non-technical users throwing up a prototype quickly is good. Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad. It's easy for non-technical users to get a false sense of confidence if the thing they make looks good. This has been true since the RAD days of Delphi and VisualBasic.
sally_glance
Knowing the industry I'm pretty sure they will all push those AI prototypes to production - because they did the same with non-AI prototypes before. Now the question is once they inevitably pull in experienced folk for maintenance, refactoring and debugging, will it be easier or harder than working with that retired solo devs spaghetti codebase?
sebastiennight
> Non-technical users pushing that prototype into production with its security holes and non-obvious bugs is bad.
I beg to differ. Non-technical users pushing anything into production is GREAT!
For many, that's the only way they can get their internal tool done.
For many others, that's the only way they might get enough buyers and capital to hire a "real" developer to get rid of the security holes and non-obvious bugs.
I mean, it's not like every "senior developer" is immune from having obvious-in-retrospect security holes. Wasn't there a huge dating app recently with a glaring issue where you could list and access every photo and conversation ever shared, because nobody on their professional tech team secured the endpoints against enumeration of IDs?
highwaylights
Having worked with it quite a bit I'm still not sure I really understand what it is, which sounds like a bizarre sentence but:
It's Postgres, but bundled with some extensions and Postgrest. And a database UI. But hosted and it runs locally also by pulling the separate parts. Running it locally has issues though, so much so that I found it easier to run a docker compose of the separate parts from scratch and at that point just carry that through to a deployment, at which point is there still a reason to use Supabase rather than another hosted Postgres with the extensions?
It's a bit of a confusing product story.
jonplackett
I really love supabase. And I’m glad they are getting some funding because I’m terrified they’ll get bought by Amazon or google and completely ruined.
The developer experience is first rate. It’s like they just read my mind and made everything I need really easy.
- Deals with login really nicely
- Databases for data
- Storage for files
- Both of those all nicely working with permissions
- Realtime is v cool
- Great docs
- Great SDK
- Great support peeps
Please never sell out.
madeofpalk
it's just a firebase competitor, that's based on postgres and you can run sql against it if you want.
eddieroger
It's also implied, and proven by some, that having access to Postgres means you can up and leave Supabase if you want to later. It won't be snap-your-fingers easy, but it's more direct than other hosted SaaS where you can't access your data or the schemas.
peab
exactly this
InstaPage
[dead]
csomar
You are not wrong that it’s a postgres + extensions. However, the tech market is very big now and that can sustain these valuations.
BoorishBears
Not really a confusing story: it's a PaaS that wants to beat fears of becoming another Parse (https://www.willowtreeapps.com/craft/parse-shutdown-what-it-...)
Realistically 99% of the users would still be screwed if they ever shut down, regardless of if it's open (see: Parse)... but it gives people a some confidence to hear they're building on a platform that they could (strictly in theory) spin up their own instance of should a similar rug pull ever occur
tough
They have also been giving back to postgres some of their extra work, and also their real time stuff i think is on erlang?
I agree you might prefer to choose the stack yourself, but for total n00bs and vibe coders supabase is a great start / boilerplate vs say the MEAN stack that was a hit 5y ago
whstl
I’ve been using Hasura and PostgREST for a few years now with real big production apps, in enterprise and in startups, and honestly the only problem with them is that backend engineers feel threatened.
They are great products that cover 95% of what a CRUD API does without hacks. They’re great tools in the hands of engineers too.
To me it’s not about vibe coding or AI. It is that it's pointless to reinvent the wheel on every single CRUD backend once again.
highwaylights
I like PostgREST for some of it's use cases (views mostly), but the issue I have with it is that I don't often want a user to have direct access to the database, even if it's limited to their own data.
Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail.
Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database.
Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.
whstl
> Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely
Congratulations: that's not basic CRUD anymore, so you ran into the 5% of cases not covered by an automatic CRUD API.
And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time.
You don't have to throw the baby away with the bathwater just because it doesn't cover 5% of cases the way you want.
It's a rite of passage to realize that "use the right tool for the job" means you can use two tools at the same time for the same project. There are nails and screws. You can use a hammer and a screwdriver at the same time.
TSiege
Experienced backend dev here who also uses Hasura for work at a successful small business. I think it's great at getting a prototype to production and solves real business problems that a solo dev could do by himself. As engineer #2 it's a mess, and it doesn't seem like a viable long term strategy.
I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns. Your entire schema is exposed. Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly. You're pushed into fake open source where you can't always run the software independently. Who knows what will happen when the VC backers demand returns or the company deems the version you're on as not worth it to maintain compared to their radically different but more lucrative next version.
I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
whstl
I completely disagree.
Backends are far messier (especially when built over time by a team), more expensive and less flexible than a GraphQL or PostgREST's api.
> I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns
Writing backend code without knowing what you're doing is also an insecure nightmare that forces anti-patterns. All good engineering practices still need to apply to Hasura.
Nothing says that "everything must go through it". Use it for the parts it fits well, use a normal backend for the non-CRUD parts. This makes securing tables easier for both Hasura and PostgREST.
> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly
I'm gonna disagree a bit with the sibling post here. If you think that going through Hasura for everything is not working: just don't.
This is 100% a self-imposed limitation. Hasura and PostgREST still allow you to have a separate backend that goes around it. There is nothing forbidding you from accessing the DB directly from another backend. This is not different from accessing the same database from two different classes. Keep the 100% CRUD part on Hasura/PostgREST, keep the fiddly bits in the backend.
The kind of dogma that says that everything must be built with those tools produces worse apps. You're describing it yourself.
> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
I have heard the arguments and all I hear is people complaining about how hard it is to shove round pieces in square holes. These tools can be used correctly, but just like anything else they have a soft spot that you have to learn.
Once again: "use right tool for the job" doesn't mean you can only use a single tool in your project.
nawgz
> As engineer #2 it's a mess
As a long-time Hasura stan, I can't agree with this in any way.
> Your entire schema is exposed
In what sense? All queries to the DB go thru Hasura's API, there is no direct DB access. Roles are incredibly easy to set up and limit access on. Auth is easy to configure.
If you're really upset about this direct access, you can just hide the GQL endpoint and put REST endpoints that execute GQL queries in front of Hasura.
> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper
> Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops
... How is an API that queries Hasura via GQL any different than an API that queries PG via SQL? Put your business logic in an API. Separating direct data access from API endpoints is a long-since solved problem.
Colocating Hasura and PG or Hasura and your API makes these network hops trivial.
Since Hasura also manages roles and access control, these "extra hops" are big value adds.
> You're pushed into fake open source where you can't always run the software independently
... Are you implying they will scrub the internet of their docker images? I always self-host Hasura. Have for years.
> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing
I think your arguments pretty much sum up why people think it's just about backend engineers feeling threatened - your sole point with any merit is that there's one extra network leg, but in a microservices world that's generally completely inconsequential.
NewJazz
I have used them too, and I would say that at least for Hasura, performance can be poor for the generated queries. You have to be careful. Especially since they gate metrics behind their enterprise offering.
whstl
This is the same for any GraphQL backend. And even REST backends can be misused: I've fixed way too many joins-in-the-frontend that were causing N+1 queries in lists.
spullara
It is really good for getting started but ultimately our companies transition off of it.
digital_sawzall
How much are you paying per month?
nprateem
It's all fun and games until you need caching - something that comes at unspecified cost from when I looked into it.
otterley
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
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
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
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
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
> 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
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.
BoorishBears
> 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
> 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
> 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
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.
hashamali
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.
bombcar
The IPO is how (the shareholders) make money, by selling to bagholders.
jihadjihad
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
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
Google bought firebase, so my guess is they are aiming for an Amazon or Microsoft acquisition.
fsndz
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
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.
lionkor
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
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
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.
colesantiago
> 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
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
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.
carlhjerpe
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
tootie
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.
returnInfinity
They are definitely creating some value. Managed database.
999900000999
>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
> 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
Hosting it on an actual server with a URL is not a fun experience. You need to generate a specific type of string to get it to work.
This isn't documented anywhere. Deep deep in their GitHub issues you'll find a script for generating this magic string which needs to be set as an environment variable.
See https://github.com/supabase/supabase/issues/17164#issuecomme...
Zekio
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
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
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
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.
balls187
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
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
How is Djanjo a replacement for Supabase?
999900000999
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
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
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.
candiddevmike
Their series C was in September 2024!
kaladin_1
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.
crowcroft
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.
siliconc0w
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'.
codingwagie
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
Both use AWS under the hood
codingwagie
point still stands
ru552
How are they giving AWS a run for their money when they use AWS for their own service? AWS profits from Supabase growth.
gabinator
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.
jameslk
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
Execs cashing out some of their shares to buy houses in Tahoe while the stock market is in the red.
joshdavham
> 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.
jbs789
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…
zkmon
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.
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.