Hey HN, supabase ceo here. The series B was announced earlier this year on Techcrunch, so this article is a bit more of a deep-dive into the round and how we'll use the funds.
I'm repeating the same comment from earlier - I want to give a big shout-out to the HN crowd. You have been instrumental in our growth - both from a traction perspective, but even more so for product development.
From our initial launch 2 years ago[0], where everyone told us we need auth, to our Auth[1], Storage[2], Functions[3], and GraphQL[4] launches. You are always giving great (and usually tough!) feedback which helps guide the team and product direction.
I'm trying out supabase db & auth for a side project and I'm very impressed so far.
I would love to have a usage-based pricing tier, as once I'm live I doubt I'll have enough users to merit $25/mo but I would still like to pay for daily backups etc
It's something we hear a lot since Supabase is often used for small projects. For now, we need to focus on building a sustainable business, and in the future we should be able to support more users like yourself as we take on larger customers.
There was an article on HN this week[0], which had a pertinent comment: "if your company wants to offer a free service, be sure that you can keep offering that for free."
We feel we comfortable that our current pricing is long-term viable, and ideally any change we make will be to lower the prices rather than raise them.
This is pretty much what keeps me from using it. The whole your project will be deleted in a week of no use thing is confusing to me too, As someone who has a full time job and wants to build stuff on weekends, my beta project is potentially killed because i skipped working on it for a weekend? Firestore is just too easy and cheap, $25 a month is a ton of money for that. Also at $25 a month my (dayjob) company will just want to use aws or azure since we already have accounts there.
Hey, congrats on the round! $80m is a monster raise, really impressive. Are you able to discuss your revenue numbers at all? I'd be really curious what type of growth you're experiencing that has allowed you to raise as much as you have, and so quickly. We've been seeing 5-10x projections on revenue for Series B, so I'm guessing you're closer to $10m than $5m in ARR.
Regardless, congrats again. The product looks really interesting, and I'll keep it in mind in the future for any projects that fit the bill.
It's unlikely we'll discuss revenue numbers unless we ever decide to go public. Doing so would make us the target of the wrong sort of attention (people analyzing our financial viability, rather than focusing on the product). See Databricks as an example here[0] - "I promise that we’re not picking on Databricks for any reason other than that it committed the well-known sin of being more transparent than is traditional during its growth phase."
It sounds like you're fundraising yourself, and if you are then keep in mind that we closed this round in April. The markets have changed significantly since them. Feel free to reach out directly if you want my personal opinions of the market conditions (my contact details are in my profile)
Multiples for Seed - Series C can vary wildly depending on a company's TAM, team, GTM strategy, among other things. I've seen series Bs at 100x revenue in hot spaces. M&As tend to be priced more consistently against revenue, due to the change in risk profile for the buyer, and even those multiples can have extreme differences.
they will make millions by offering a standard, battle tested, open source, managed backend "distro" for people who have better things to do than handroll it every time?
Not to crash the party or anything. Supabase is great and all (congratulations BTW on such a huge series B!) but in terms of feature completeness and getting actual products built, it doesn't come close to Parse[0].
Same with Appwrite. Both of these are very popular but they either lack essential features or have them behind a subscription wall. For example, the OSS version of Supabase (last I checked) doesn't include the edge functions which are really important for easily computing stuff on the server side. Parse on the other hand is 100% open source and has a huge feature set. It's older than all of these lo-code tools and actually helps solve the issues one comes across when using such tools.
Another thing is extending these tools which is a pain. For example, Parse supports multiple databases by default (postgres & MongoDB) and the ability to write a custom adapter if you need something else. Similarly, if you at any point need to go 100% custom it also makes that possible so you are never locked in. These tools however don't have that level of low-level control and are general all or nothing kind of tools best for small-to-medium sized problems which don't have a lot of room to grow.
But both of these (Appwrite & Supabase) are super markety. Appwrite is all over the place with their ads, Supabase got a huge trend when it launched etc. Parse on the other hand is not too good at marketing their product being fully community run which is one reason not many know of it. Another is their not-so-fancy docs.
I have no stake in any of these products: just my conclusion after having tried all of these.
Looks like Supabase does support edge functions now.
I've inherited a Parse codebase in the past, and thought it was pretty gross. You're stuck building with their ORM abstractions, so it hurts when you need to do something complex. I view Parse as Facebook abandonware that's been salvaged by a community of developers who need to maintain legacy apps on life support. I think it'd be unwise to start a new project backed by Parse.
Having to deal with one-size-fits-all database "adaptors" for either Mongo-flavored or Postgres-flavored Parse is limiting, whereas having direct access to Postgres is a huge benefit of Supabase.
With Supabase, you can leverage all of the goodies that Postgres has to offer, which is exactly what I want as a developer. Even something as simple as writing custom SQL is a well-defined operation within the Supabase ecosystem, whereas with Parse you're in undefined glhf territory. Add that to first-class support for realtime updates, row-level security, and their other features, and Supabase comes out way ahead in my opinion.
All of those are supported in Parse as well. ORMs are a feature, not a bug. Writing SQL is all well and good but if you have GraphQL, it's not an issue. I think the whole point behind tools such as Supabase & Parse is a well defined & safe set of defaults which can easily be customized if the need arises. Parse is very well suited for this as you can custom endpoints, custom pgsql functions, custom edge functions in multiple languages (Go, Node etc) etc. Supabase is not that customizable.
Sure, Supabase has a huge funding etc and it might get there someday but if you are into self-hosting (from which POV I am speaking), Parse comes out way ahead.
This is textbook startup strategy: new companies disrupt incumbents with products that have less features. The startup finds a pain point in their audience and delivers on that. I don't know about Supabase enough to comment, but your assessment of them having an inferior product + their popularity makes me think the 'disruptive innovation' process is on its way.
Having less features makes it easier to talk to users about their main issues and reduce friction in onboarding/setup/etc. Maybe Parse became so complete it's really hard to get started.
I guess my doubt is, what's the point you are trying to make? That their product isn't good enough to warrant so much attention + funding since there are better options, that it's just marketing and good docs and everyone is just being fooled into using a lesser product?
I like Supabase's SaaS model because I don't have to worry about infra work; I can just build.
Maybe eventually I'll have to explore other options, but for now my projects are still small enough where their feature set meet my needs. I think $25/mo is well worth it, knowing:
1. I can spin up a db & auth for a new project without having to spend hours on configuration & deployment
2. I can sleep well at night not worrying about one faulty line of code bringing down my entire app
True as that may be, in a production app I don't think breadth of features trumps having paid support, SLA's, comprehensive documentation, resources, tutorials etc.
On top of that, funding like this gives a pretty optimistic outlook on the future of the project when compared to a fully community managed open-source project that could become abandonware.
I really love Supabase -- so much so that I'm wondering if I can just take all their ideas, open-source contributions, and self-deployment guides -- and then just create a company to compete directly against them. Would that in fact be good for Supabase by forcing them to up their game (assuming I'm competent)? Is that what the magic of building a company with code in the open is?
This is a really interesting question that highlights the nature of open source and businesses. It is basically what Amazon did to many open source projects such that they've become non-open-source now, like MongoDB and ElasticSearch.
So I can make even more money? If they have a great idea and great execution and are going to make a ton of money, then maybe I should take all their stuff, offer it for $1 less, and then take half their business.
I think its just a fun things newer companies are doing, especially developer focused ones. Noticed it on a few websites of newer SAAS businesses like this.
Supabase and Directus are my go-to BaaS offerings. In terms of developing server side code(custom backend logic) Directus is still better than supabase. Also the Admin Interface is more capable. However in terms of performance supabase is of course way better. Lucky that we have such good options nowadays.
Mind sharing an example tech stack with directus? Are you using it for auth as well? Been playing with it recently - wondering if I use directus as the CMS, and use something like firebase for auth? Thoughts?
I see supabase as a missed opportunity to innovate in a space that desperately needs it. It could have been a product that fundamentaly reimagined the developer experience of working with a database. Instead they opted to mostly stick to the existing sql paradigm combined with some firebase-mimicking features. So what they end up with is a service that offers some marginal improvements over other, established database services but nothing truly game-changing.
Postgresql is itself a game changer for this kind of service. There was firebase, fauna, and some others, but no actual honest to god SQL. And thank god that it's postgres and not mysql.
I'll be honest, at this point i have no idea why I like postgres more than mysql, but I have a feeling there's a good reason for that and I don't really want to re-learn why.
True. And to be clear I’m not arguing to reinvent it, but rather to build on top of it. SQL and traditional RDBMS are extremely powerful, but also vast, complex and difficult to master. They have for many of us a rather painful learning curve that could potentially be taken away by a product/service that creates the right kind of abstraction. In my opinion supabase does however not go far enough in creating this abstraction.
Broadly speaking: a developer-centric Airtable. A low/no-code environment to create and manage your database combined with a top-notch SDK that is automatically generated and easily accesible from within the UI. The idea being that a frontend developer or hobbyist with no backend/database/sql knowledge whatsoever could easily get a properly functioning database up and running for a (fairly) complex app.
Thanks for the feedback. I'll share this with the team.
In the long-term we definitely want to be as easy to use as Airtable. We won't ever build a DSL on top of SQL, but we think we can create a UI that gives 90% simple use-cases and then you only need to reach for SQL for the remaining 10%, or as an escape hatch for advanced use-cases.
~~In case it wasn't clear already from our site: we already have an Airtable-like UI, SDKs, auto-generated APIs (which you can use to auto-generate your own SDKs) - perhaps these aren't yet as simple as you imagine they could be?~~
e: I see you responded to a sibling comment. I have sent a link to the team with your feedback
> The idea being that a frontend developer or hobbyist with no backend/database/sql knowledge whatsoever could easily get a properly functioning database up and running for a (fairly) complex app.
So, Microsoft Access for the web?
Believe it or not there was a time in the late 90s you could nearly HyperCard for the web using low code “wizards”.
Not sure what happened, maybe server-side JavaScript or things like Django and Ruby on Rails released a pressure valve.
For one thing the fact that you can't really properly use Supabase (apart from some very basic functionality) without having at least some knowledge of SQL, postgres and databases in general. IMO you'd even need fairly in-depth SQL knowledge to understand the Supabase docs and examples.
I mean to push back a bit on this -- they have a pretty intuitive GUI that they've open sourced for working with the database at a less SQL-focused level. It isn't exhaustive but for basic things like adding / editing columns, or database policies, it's pretty nice.
That's not to say there isn't room for improvement, but if you look at the github issues on all their repos, and the commits that have come out in the last few months, it's pretty clear they're pushing the way you want them to go RE simplifying the more complicated pieces down to manageable chunks.
I’m not saying it’s a bug. But I wouldn’t call it a feature either, but rather an obstacle in the way of a better/easier/faster/more enjoyable developer experience.
yep, a bunch! in production it's mostly small projects with only a few collections and simple CRUD. the auth providers are nice, i'm excited to work with subscriptions, and not having to provision anything makes it easier to say yes to an idea. migrations took some getting used to, could use some tooling, but zero downtime is worth the fiddliness. it's my go-to for new projects now--for most things, i can get away with fauna, auth0, and a few edge functions as my whole backend
Conspicuously missing for me from the graphs is anything indicating revenue. It's easy enough to get users if you give them free stuff. But a startup database company has an inherent weakness. Given how foundational databases are to a lot of projects, it's the technology choice where people are most inclined to pick safe, boring choices. I'm sure they're getting people to try it out, but how many of them are putting major things on it?
If it's that boring, then why use it? Postgres is easy enough to install and there are plenty of reliable, profitable vendors providing it as a service.
Presumably among their add-ons are features compelling enough to sign up to pay for ongoing service fees. But then what happens to the apps that depend on them if the company goes dark? We could well be entering the sort of extended recession that results in a venture capital drought.
I mean, the thing that got me to try Supabase was that they had the most generous free tier for Postgres that I could find, didn’t even care about their other features.
I don't know. Open-source for simple things such as how to talk to a database is overly crowded. It is not as simple as "have a free product and people will come" any more which may be true 10 years ago.
All I am saying: it took a lot of marketing to get yourself out there even if you give it for free nowadays.
With Supabase being a very similar product to Firebase, with the addition of a self hosted version (something that is hard to profit off of), what is the plan for the future in getting market share from Firebase users? I can see that GraphQL was added recently and that is a great feature that Firebase doesn't have, but features like that don't move significant people from Firebase to Supabase.
it is honestly only superficially similar. Firebase has a proprietary nosql database, which is costly, lockin-y, and inflexible. Supabase uses postgres, which everyone can host, so the incentive is to compete on developer experience and moving faster on features than firebase can.
when was the last time you saw anything firebase shipped on HN?
Moving them from Firebase is perhaps the wrong action to measure initially.
Instead, look at new projects only (not existing). If a large % of new projects start with Supabase instead of Firebase then they will eventually have a large number of total users (to monetize).
Ideally, for Supabase as a business, this would combine with churn eroding Firebase's project/user count. And that's the story of how Supabase will eventually get acquired by one of the FANGs.
firebase could have real staying power. there's just so much value in the ecosystem already that i don't see another community replicating in the next five years. the nativescript firebase plugin is a great example of how firebase can save you hundreds of thousands on build
Looks like I could have written that better, I meant to ask what Supabase's plan was to be a better alternative to Firebase, since Supabase is new and has exciting features going for it, while Firebase is old, stable, and has Google backing it with tons of content on YouTube, Medium, etc.. And this isn't me trying to be critical of the Supabase, I love what they are doing, just curious on the business aspect.
The parent comment is actually quite accurate (disregarding the FAANG acquisition - that's definitely not our plan)
We chatted to a lot of developers when we started building Supabase - all of them loved Postgres, but when we asked what they were using a large portion of them chose Firebase, because it was so much easier to get started with. They even knew that they would need to migrate away from it at some point.
So that became our goal: make Postgres as easy to use as Firebase. We're starting to shed the "firebase" positioning now. In the mid-term, you can think of us as an "open source RDS alternative", and eventually we'll be more like an "open source Aurora alternative" (with some extra bells-and-whistles)
Congrats! In terms of metrics demonstrated, showing cumulative growth charts is not helpful (vanity metric, always goes up to the right). Monthly incremental growth would be better to demonstrate product-driven growth instead. The chart with regards to React seems to show Supabase slowdown. That said, raising money in this environment is great and progress matters. Good luck!
I'm repeating the same comment from earlier - I want to give a big shout-out to the HN crowd. You have been instrumental in our growth - both from a traction perspective, but even more so for product development.
From our initial launch 2 years ago[0], where everyone told us we need auth, to our Auth[1], Storage[2], Functions[3], and GraphQL[4] launches. You are always giving great (and usually tough!) feedback which helps guide the team and product direction.
[0] https://news.ycombinator.com/item?id=23319901
[1] Auth: https://news.ycombinator.com/item?id=24072051
[2] Storage: https://news.ycombinator.com/item?id=26635184
[3] Functions: https://news.ycombinator.com/item?id=30868849
[4] GraphQL: https://news.ycombinator.com/item?id=30846006