[smalltalks]

Everything said above is true.

Supabase started Open Source , their GitHub repo had tutorials on how to host the platform yourself with a bit of documentation. Basically from what I understood they've been growing SO FAST ( they raise 10+$M IIRC ) they had to make a choice between "Growth" or "Integrity".

Obviously it's a YC company , the market they're going after is massive , they chose growth over integrity and doing things "that don't scale" but that have "traction".

I agree with the author , the founders should come clear about the marketing and the status of Self Hosting and Open Source... Supabase is no where near Open Source as it promised when it was published on HN few months ago... It's getting closer to a "MuleSoft/Serverless Inc" type of thing that lets you connect your own providers...

Don't get me wrong , I'm saying this because I'm an Enterprise Architect in one of the largest Bank in Europe , I desperately need an Open Source Firebase Clone to move 300+ Developers and Business Analyst into a Cloud First / Product Focus model away from legacy Cobol Enterprise App, Supabase seemed the ideal candidate.

Unfortunately it has been a huge deception.

[kiwicopple]

Every component of Supabase is MIT, Apache 2, or Postgres licensed - apart from the dashboard

The code to self host it is in our main repo: https://github.com/supabase/supabase/tree/master/docker

I do think we could have better/cleared docs, which we can fix up tomorrow.

Re investment: we raised 6M, and we are under no pressure to trade our integrity for growth. We have open-source-friendly and patient investors (Mozilla, Coatue, YC), and a nice group of developers: https://supabase.io/blog/2021/03/25/angels-of-supabase

[CobrastanJorji]

Is there a difference between Firebase's "open source" and Suprabase's "open source"? Is Suprabase more open than Firebase in some manner, or does "an open source Firebase alternative" just mean "a Firebase competitor that also open sources its client side tools?" Is some part of the Firebase code closed source or less "Open" where the Suprabase equivalent is not? I haven't used Firebase much, so maybe I'm missing a big distinction.

[kiwicopple]

> Is some part of the Firebase code closed source or less "Open" where the Supabase equivalent is not?

All of the Firebase backend is proprietary, and their client code is open source.

The Supabase backend is here: https://github.com/supabase/supabase/tree/master/docker

This is the set up we use for every project on our hosted platform. These backend tools are either built by Supabase, supported by Supabase (we employ maintainers), or licensed with OSI-compliant licenses.

Our client libraries are all open source, Apache 2.0 licensed.

Supabase is open source in every definition of the word. I think the problem is our self-hosting docs, so we'll spend the day improving this.

[CobrastanJorji]

Ah, gotcha. So Supabase has backend that is also open source which could theoretically be used for self hosting? Yes, that is a difference. It wasn't clear to me from the docs. Thanks!

[monstermachine]

Firebase is completely closed source and make it extremely hard to migrate any moderate size project.

Supabase builds on open source parts that everyone is already familiar with. Postgres for data store instead of firestore (which is a proprietary nosql Google cloud database with many quirks to keep you in). GoTrue for Auth which is an open source project by netlify. Real-time to provide Postgres changes over sockets open sourced by them. There are many parts which make up "supabase".

Supabase hosting provide a unified experience through their dashboard and manage all these parts for you. That isn't open source.

The actual UI kit for that is open source, though.

Dashboard doesn't stop you from migrating your backend infrastructure somewhere else. It does result in degraded developer experience which can be the biggest distinction.

[turtlebits]

They provide a Docker image, Dockerfile and a docker-compose to run the whole stack.

I'm assuming it should be relatively easy to point their client at your own instance and they should work.

What more do you want?

[rattray]

I think what more they want is the dashboard, which isn't open-source or self-hostable. Sort of fair ask, but also pretty fair for Supabase not to provide that IMO.

They also want better self-hosting docs, though IMO it's fair for that to be primarily driven by community forums.

[cpursley]

https://hasura.io/blog/firebase2graphql-moving-from-firebase...

[nicoburns]

Why do you need a firebase clone? Can't you just use postgres the traditional way?

[kiwicopple]

Supabase started because we open sourced a "change data capture" server on top of Postgres[0]. We then chatted developers to see if they wanted to use it. In our conversations, many of the developers were using Firebase because it was "just easier" to get started.

We really like Postgres, so we decided to make it as easy to get started as Firebase. We aren't modifying Postgres, or trying to turn it into something proprietary. We want migration to/from to a simple pgdump wherever possible. We provide some tooling around it to make it a better experience (for example, auto-generated APIs using PostgREST).

[0] https://github.com/supabase/realtime