DEV Community

loading...

Discussion on: Supabase: ten months of building.

Collapse
johncarroll profile image
John Carroll

As a Firebase user, I was surprised to see that Supabase's API is completely different from Firebase's. With a definition of "firebase alternative" this loose, I gotta say: an open source Firebase alternative already exists and it's called Hasura. Obviously there's enough room in the world for multiple open source projects addressing the same goal, but, after looking at Supabase's website, my thought wasn't "Why would I choose this instead of Firebase." It was, "Why would I choose this instead of Hasura?"

Collapse
jcs224 profile image
Joe Sweeney

I've used Supabase, but not Hasura or Firebase. Some surface-level differences I see from Hasura:

  • Supabase doesn't use GraphQL, just JavaScript. When you want to fetch data, you write straight-up JavaScript for querying data and setting up real-time subscriptions. No GraphQL at all. I believe this makes Supabase more similar to Firebase than Hasura.

  • Authentication is handled in Supabase, whereas it's deferred to another service in Hasura, according to Hasura's own docs. Authorization/role-based access in Supabase uses Postgres's built-in Row Level Security, whereas Hasura does it the GraphQL way.

I've played around with Supabase and quite like it! I'm excited to see what they come up with for their Functions feature. To me, that would be a real game-changer.

Again, never used Hasura, or even GraphQL. Supabase is a more appealing API to me personally.

Collapse
mattymaloney profile image
mattymaloney

In what manner is this similar to Hasura?

Collapse
johncarroll profile image
John Carroll

Honestly, I don't think Supabase or Hasura is that similar to Firebase. But, if you argue that Supabase is similar to Firebase, then Hasura is also similar to Firebase and hence Supabase and Hasura are similar to each other. Each provides real-time database subscriptions, an authorization/authentication layer, ability to call server side functions, etc. The three have completely different APIs, and Supabase/Hasura rely on a relational database vs Firebase's NoSQL database, but the high-level Supabase marketing materials seem to ignore that. My point is that equating Supabase and Firebase to one another seems like a stretch to me but, if you're going to go there, it raises some additional questions that seem to be unaddressed (for me at least).

Collapse
supabase_io profile image
Supabase Author

Hey John, thanks for the feedback. We're implementing the features of FIrebase, but we're not creating a 1:1 mapping. For example, we use Postgres instead of a NoSQL store. This is on purpose - we want to make the platform scalable, and Postgres is proven to scale.

Why would I choose this instead of Hasura?

Probably a matter of preference! There are quite a few similarities. Joe highlighted some of the differences in his response.

Ultimately we're both open source and contributing to other open source tools like Postgres, so it's great for you and the community :)

Collapse
johncarroll profile image
John Carroll

We're implementing the features of FIrebase, but we're not creating a 1:1 mapping.

Fair enough. I guess the point I was trying to make is that, for me (a Firebase user for about 2 years who is aware of, but has never used, Hasura), I don't find the current Supabase marketing materials that compelling. But it's important for me to acknowledge that, in general, I'd rather use a GraphQL API than another proprietary javascript one. While I like the Firestore API, it's definitely a negative that it's proprietary.

Ultimately we're both open source and contributing to other open source tools like Postgres, so it's great for you and the community :)

You are correct! Best of luck.