Supabase (YC S20) – An open source Firebase alternative

I am ecstatic that someone is finally taking on Firebase. As a Firebase user, I find it invaluable. Their free plan and limits are very generous. The fact they offer not only a database, but authentication, hosting and perhaps one of their biggest features besides authentication: Firebase Functions. I have API's in deployment that are solely running using Firebase Functions and using Firestore as the database. The CLI is also another huge Firebase feature.

Following this intently, because Firebase has no true competitor, let alone an open source one. Nice work so far.

I see from the links that this is probably borrowing a bit from Postgrest? I've just discovered Postgrest in the past few days and along with Postgraphile it seems like all of these projects aimed at "getting back to the database" are a good idea, I like it. It always bothered me that the first order of business with any software development framework was to provide a root/admin database connection. It's like, this thing just explicitly said we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead.

The lasting impact of Firebase is it proved to the world that being opinionated about the database in order to provide good tools is a viable business model, rather than force ORMs onto people to try and appease every different database flavor under the sun.

Good luck to you guys, I like the trend.

Recently released similar thing for gRPC + Go + PostgreSQL stack: https://github.com/sashabaranov/pike/

Features include:

• Generates CRUD operations for given entities

• Generates SQL migration files

• Gives developer full control after project is generated(nothing added on top of raw SQL/Go)

• Minimal dependencies(basically lib/pq and grpc)

• TLS out of the box

I am a strong believer that Firebase model is the way forward. Huge fan of Firebase but it is scary to have no proper alternatives. Yes, sure you can have a similar setup with AWS or bespoke implementation but they are not in the same spirit.

Very glad to see people working on alternatives.

IMHO though, what makes Firebase special is the glue they use: Account management and libraries come for free so you can start thinkering on the interesting parts. Firebase is not just Firestore, it is a set of tools that work together seamlessly.

When this is achieved, your own product feels mature as if you are working on implementing a product on top of FB or other established platform and everything "boring" is handled by someone else.

In my mind, Firebase is a very flexible CMS with sane defaults.

This looks great, however at first peek it doesn't mention anything about auth. Do you have any plans for that? For me this is the topic I most want to just delegate to the service.

Dashboard, realtime stuff, etc are great too. RESTful APIs I can of course get with PostgREST [0], which is insanely excellent, so the value I'm looking for is to have everything managed, from hosting/storage, to security, to all the other annoying nitty-gritty that I'm likely to get wrong.

[0]: https://postgrest.org

Guys, check out https://github.com/deepstreamIO - open source MIT - I've been a long time user and it works great. It's a typescript code base, very readable and straight forward, uses protocol buffers for messaging and uWebSockets.js for the websocket server (ultra fast). You get realtime records, pub/sub, events, rpc, fine grained permissions, http endpoints and basically you can hook up to any backend (currently there are connectors for postgres, rethinkdb, elastic and others).

We need more people to use it, cause the original developer is going on maintenance mode and we're trying to strengthen the community. It rocks!

I've been thinking about the need for easier to use databases for a long time. I previously started a company based on selling database software, so I've seen a lot of problems in the space. I honestly most databases are too hard to use and there's been no major improvements here in the last few decades.

Take Postgres. You write code in SQL, a programming language unlike any other mainstream programming language. Instead of writing code with for loops and if statements, you write it with joins and where clauses. On top of that, Postgres has a "magical query optimizer" that takes your SQL and figures out how to execute your query. Unless you have a good understanding of indexes and how they impact the query optimizer, you'll have a hard time getting Postgres to be fast. I still regularly say WTF when optimizing Postgres queries even though I've been doing it for years. That's not to mention there's tons of database specific terminology like tables, rows, schema, etc, that you have to learn before you can become an effect user of Postgres.

As much as HN likes to bash it, I think Mongo has done the best job of creating an easy to use database. With Mongo, you can store JSON and you can pull JSON out. Of course, I would never use Mongo personally.

I'm hoping that Supabase is able to bring about the next-phase of databases by not just making it possible to make a database fast, but by making it easy to do so.

Was going to quip that I built a homegrown version of this in elixir which is the best stack to implement something like this if you want it to be scalable.

Then I saw that THIS was written in elixir.

That made me take this much more seriously!

Congrats, the project looks solid. It's obviously targeted to JS devs who are familiar with firebase or want an easy/similar abstraction for realtime apps. It's great to have several great frameworks tackling the same problem with different flavours (Hasura, Phoenix, Supabase, etc), all with postgres as first class citizen.

I feel like the key is in the choice for the realtime backend (Phoenix/Elixir). I've built real-time firebase apps (JS) in the past and today my choice would probably be Phoenix. It also saves many LoC (80-90%?), and it's a joy to work with. Reduces the JS fatigue and opens up a new paradigm that makes programming fun again.

To be a Firebase alternative, you would expect a full-stack solution; DB, Auth, Cloud Functions, Analytics...etc. That's the main selling point of Firebase.

This just seems to be an Open-Source implementation of Firebase's "Realtime Database", which is kind of superseded by the new "Firestore", which is much more popular.

However it's a smart business move, as many products are locked into the "Realtime Database", so this could provide an easy exit door to Open-Source software.

A bit of a plug, but if you wish for something that has the Postgres reliability, the taste of nosql but with strong typing and a json output a la graphql, give a try to edge db:

https://edgedb.com

The team behind it is awesome (one is a python core dev), and it's a FOSS, but they have been using it internally for some time.

My app is currently built on top of Firebase but I’m keenly aware of the cost of lock-in as traffic escalates.

Is this a replacement for the whole suite of Firebase offerings (hosting, auth and data store) or just a subset?

What’s the migration pathway for someone currently on Firebase?

The thing that's really invaluable for me is the firebase javascrpt implementation. Saving the state in a web app and new Objects being addable/editable offline with firebase automatically synchronising when network is available with me doing absolutely NOTHING is absolutely insane. Having just the API isn't really going to cut it.

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News.

This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from.

I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this:

  * Pick a database
  * Spin up a server
  * Connect the DB to the server
  * Create a REST API for the server so the client can talk to the DB
  * Somehow make that secure enough
  * Write a bunch of CRUD code on the client

What a waste of time! Glad to see people like Supabase taking on this problem as well.

1. I liked that the nodejs example shown here uses async await syntax. I don’t get why people still put callback hell examples in 2020.

2. What I really like about firebase is firestore is a scale to zero database. It doesn’t cost me anything if I have tiny amount of data and low frequency of users. This lets me spin up lots of small sites at no cost. With cloud run I have a real api server that also scales to zero. My last GCP bill was 3 cents. And yes, GCP was dumb enough to actually charge my credit card for that. Not sure why they don’t have a $1 minimum.

But I like what I’m seeing as supabase’s pitch.

Good luck! It’s great to see another BaaS alternative on the market especially the recent trend seems to be a lot of Jamstack (backend-less?)

Hopefully open source means better documentation too. Only places I know for Firebase are their docs and own YouTube channel, which can feel limited once you pass the “get-started” depth

co-founder here, happy to answer any questions. We're currently in alpha - app.supabase.io

We also have a lot more to build, so to reward you for your patience we are completely free right now

This is really interesting. I spent a while a few weeks ago looking around for a serious, open-source BaaS effort backed by... anyone.

I've been influenced by code generators like xo/xo [0] and sqlboiler [1] recently (so you can have type-safe APIs and you still manage/own the resulting code).

My bet is that you can generate an entire API _and_ basic CRUD browser UI from a db schema. I've been working on a code generator that does this. It can currently generate an entire Go REST API with CRUD operations from a PostgreSQL database. Next is to generate a React/TypeScript UI and add auth support.

The advantage a project like mine has over this is that it defines a standard API specification and you can build an APIs and UIs against that standard. Right now the only API is Go, but I'd like to build a Java one too and would be open to community submissions.

Same thing goes for database dialect. Right now it's PostgreSQL only, but this kind of code generation can be done on any database once a driver is added.

Won't link to it here because the whole thing is WIP but it's on Github. I see this kind of project as a long-term base for rapidly building any sort of db-based applications in the future.

[0] https://github.com/xo/xo

[1] https://github.com/volatiletech/sqlboiler

The advantage with firebase web sockets is that when they inevitably get blocked by firewalls you can always say "Would you mind whitelisting google? Thanks."

isn't this more like "An open source Firestore alternative" right now. Do you plan to bring other features as well?

I'm a big fan of firebase and use it whenever I can. The reason it's appealing it because it's the suite of tools and how well they work together for bootstrapping (auth, firestore, storage, analytics etc). No single feature by itself is useful to me.

I would definitely switch if this atleast had (auth + db + file storage + functions).

I'm a big fan of Firebase and have seen a lot of projects get up and running very quickly and scale as well.

However, I think there are an increasing amount of reasons why you want to have your data stored in a SQL database that you can access. The open source tooling being built around SQL (usually Postgres) as a standard is becoming better and better and it's going to be hard for Firebase to compete with all those offerings. If I run a Postgres database I can instantly have tools like Hasura [0], Metabase [1] along with others that add a ton of value out of the box. However, maybe those tools will also integrate with Firebase.

Anyway, my point is that this is best of both worlds, so great to see!

[0] https://github.com/hasura/graphql-engine [1] https://www.metabase.com/

This looks to just be the "real time" DB? How is this different from using GraphQL subscriptions via Hasura/Postgraphile, or RethinkDB?

Also, it seems like it's missing everything else that Firebase provides. Authentication, authorization, storage, hosting, etc. To me, Firebase's value prop is more than just a database.

Finally, waiting for something along the lines of these. Firebase is kind of the poster child for vendor lock in, and has been around for a long time. It's time we have some healthy competition.

The biggest feature I will be looking for in this is a true push to android mobile devices. It looks like you can use the subscribe function for this, but I'd need an android example to get up and running quickly. Right now it seems like firebase is the only game in town for that functionality unless you want to roll your own with websockets or some sort of MQ. Google also strongly encourages use of firebase for that in the TOS in the play store I believe. I'm very excited to see how this progresses.

I also went right to the pricing page to see if you would charge for on-prem hosting, but looks like it is still TBD. I would like the ability to host everything on-prem. Security and encryption would be next on my list of wants after that.

Couldn't find the info on the website, does the JS shown in the samples run in the client's browser? If so, I'd be coupling my client code to the implementation details of my server side DB. Nope, no thanks. Too many scars to fall for that again.

If you use Mongo, you could easily use just `@ladjs/api` package from the Lad framework https://lad.js.org. Deploying is simple, and you don't have vendor lock-in.

This is a simple example of a `GET /v1/account` API request controller: https://github.com/ladjs/lad.sh/blob/4d0a5b5ff822d07e855bbe1...

If you use SQL, you can submit a PR with `knex` and `bookshelf` option and I would gladly accept it.

For those signing up - we have hit our cloud limit. we are getting in touch with them now to increase the limit

Interesting. I haven’t seen a log shipping mobile sync solution in quite some time. Sybase SQL Remote did log shipping for SQL Anywhere over email or messaging. This tech predated WiFi, never mind HTTP/JSON.

There is little information about the client side data store other than the fluent Query Builder API. Is it IndexedDB? How does it handle primary key generation? Can the client sync a subset of the DB or do you expect to have a dedicated cloud PostgreSQL instance for every client?

How do the querying features compare to Firebase? Firebase is notorious for having an unintuitive lack of server-side query options when you start using it.

I've only just begun exploring it, but it seems like AWS Amplify is another strong alternative (just uses underlying AWS services, but with a nice CLI that ties it all together). Not open source of course, but it's striking to me that people are only referencing this project as being an alternative to Firebase - is Amplify not seen as that strong of a product?

This looks great (both Supabase and Nhost)! Years ago I wanted a self-hosted version of the real-time subscription of Firebase and had come across DeepStream[1]. It now seems to be in maintenance mode due to lack of contributors and maintainers. [1]: https://deepstream.io/

Wow this just made my day! I am building an open source data management software (aka admin). I am happy to see more software focused at data.

Yay!

I've recently been playing with firebase and looking for a non-google alternative. Looking forward to giving this a go.

I like this trend of creating a free / low cost version of an entrenched product & then supplementing with SAAS revenue.

However, the real reason these companies are worth so much is the stock market & careful stock manipulation carried out by Wall Street firms.

It's a game of using most of your money for AdWords & marketing.

The trick is to grow your revenue at a rate like 40% yoy, starting at a rate of about 100% and then slowly declining down to a 40% rate.

Of course you pay for this with ad dollars. Wall Street really does not care how you obtain that growth, just that you do obtain it & every quarter you "surprise" the analysts with a little more revenue than planned.

In the beginning you can spend lavishly on SG&A so that it's an easy target for reductions in the future.

And in the beginning you take out massive amounts of money with stock option grants.

Anyways, my observation is that we could use a Stock Wealth Maximization as a Service.

From what can be understood: Writing a backend with Supabase will turn into managing all these servers.

Backend Server = Supabase (for realtime) + PostgREST (for REST APIs) + Serverless Functions (for business logic) + Postgres SQL database.

For somebody using Firebase today, How will this solution with Supabase be simple to manage and scale ?

Help me understand if I am wrong.

I have been working on a Clojurescript wrapper for the Firebase (Firestore) database. Here is an interactive example of the principle features of that work. Comments and criticism (and PR's) welcome!

https://firemore.org/

A plug here, but we built an app around tracking Firebase usage and costs because there it a worry about getting a big monthly bill. Check it out at https://www.firerun.io

The problem with these BE services is, unless you refuse to sell out, I can't reliably build a platform using you.

Google will eventually offer a lot of money to buy you and shut you down. Prove to me that isn't going to happen.

Their pricing model is interesting:

https://supabase.io/docs/pricing/

I wonder what the "investors" mailing list is about.

Seems more similar to Hasura than to Firebase. Firebase adds functions, file storage, and authentication on top of the database. I didn’t see any of that mentioned on the site.