Hacker News Reader

Comment by mateomorris | Hacker News Reader

Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.

View on HN

wow, that's a glowing recommendation. Thanks for the kind words.

We have a long way to go to catch up with Firebase on most features, but of course we are benefiting from all the hard work that other OSS tools have already delivered. Postgres does most of the heavy-lifting, PostgREST is amazing, and Netlify's GoTrue server is a key piece of our architecture.

I'm curious about GoTrue, isn't that MySQL only? So do you guys run MySQL for the users database, or?

We run a fork of GoTrue, using the migrations in this PR:

https://github.com/netlify/gotrue/pull/254

tbh, our fork[1] has deviated a bit from Netlify's so we need to spend some time with them upstream'ing any changes that they would want to merge (perhaps magic links, Azure logins, OAuth scopes).

Long term, I think we will need to run 2 different forks because we have different requirements for multi-tenant. So the benefit here would be sharing "OAuth providers" (eg, if we add Okta, we upstream it, if they add Twitter logins, we pull it)

[1] https://github.com/supabase/gotrue

When you say firebase, are you also referring to Firestore? Because Firestore is way more powerful.

I am. Firestore is powerful but it’s still a non-relational database, compared to the power of Postgres on the Supabase side

Not even close to as powerful as postgres.

"Powerful" maybe for the pub/sub capabilities that allow you to trigger actions on write and whatnot?

I don't know if Supabase has this, but at any rate I don't find anything else about Firestore "powerful", it's just a NoSQL database with all the pitfalls of NoSQL, a more limited API than MongoDB, a terrible data explorer UI, and very limited local capabilities...

> Even if it wasn’t open source it would still be a better alternative.

Well, it's not hard to imagine that, since they don't provide a way to self-host it.

Hope this helps: https://github.com/supabase/supabase/tree/master/docker

I think this is a bit disingenuous to post. Your own website[1] says:

> Supabase is an amalgamation of 5 open source tools (and growing). We don't have a simple way to install everything on a single server, but we will work on this as soon as we have a stable set of features.

Now, it's fair to say "we don't have a simple way" is different from "we don't have a way at all," but you clearly discourage users from trying to self-host right now for any reason beyond developing Supabase itself (which appears to be the use of the Docker Compose setup you have linked).

Personally: I'd love for Supabase to have a clear guide for self-hosting, including system requirements for single-box hosting, advice (even without code or tooling!) for scaling your setup, etc. Until then, it's just another hosted service with vendor lock-in, no different from Firebase to me.

[1] https://supabase.io/docs/faq#how-do-i-host-supabase

>> It's just another hosted service with vendor lock-in, no different from Firebase to me

Couldn't agree more. They are real shady every time self hosting comes up.

See here ==> https://news.ycombinator.com/item?id=26637360

That's fair, to be honest those docs were written a long time ago and haven't been updated. We're releasing our CLI tomorrow, which is part of the "self hosting" story, so I'll update these docs with some detailed instructions.

Thanks for the candid feedback.

Reply on news.ycombinator.com