Supabase Series B
supabase.com
supabase.com
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
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
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.
Supabase is open source, run it yourself.
what exactly is your question trying to do here
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 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)
[0] https://techcrunch.com/2022/04/19/rethinking-databricks-valu...
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.
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'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.
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.
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
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?
good luck.
https://supabase.com/lawyers.txt
Its noted in website footer. I know there is robot.txt but lawyers ?
We call it lawyers.txt because every time we're fundraising the lawyers ask for it.
https://www.se-radio.net/2022/05/episode-511-ant-wilson-on-s...
usual answer is devs love postgres for the feature set and ecosystem, sysadmins love mysql for the simplicity.
Business is data and SQL is where data goes.
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.
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
Chance you would be up for a user interview/chat about this? My email is martin @ username . com
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.
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.
All I am saying: it took a lot of marketing to get yourself out there even if you give it for free nowadays.
when was the last time you saw anything firebase shipped on HN?
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.
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)