Hacker News Reader

Comment by justsomeuser | Hacker News Reader

With Firebase you have a team managing the service uptime.

When I last checked, Supabase is a group of processes that you manage yourself.

This means that:

- A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be massive.

- B. You are tightly locked in. Once you code against the Supabase API's you will not be able to move your app off of it. Other API's lock you in too, but because Supabase does so many things you would need to replace a lot of functionality all at once to move away.

View on HN

Supabase developer here. Firebase has a team managing service uptime. Supabase has a team managing service uptime. If you self-host Supabase, you have to manage uptime yourself. You can't self-host Firebase.

Regarding lock-in, you're pretty much right here, but this is going to be true of your entire stack. If you choose to develop your frontend in React, or Angular, or Vue, you're going to be locked into that framework.

"...because Supabase does so many things..." is a good thing, IMHO. You can choose to use any or all of our product, and each piece you choose is open-source. If, say, you choose to use Supabase Storage, and you have an issue with it, you can switch to something else but still use Database, Auth, and Functions without bringing down your entire project.

At some point you’re married to something right? At least you can Supabase to be self hosted even if that has warts.

You just can’t do that with Firebase

Though I’d argue that people overthink the value in being able to self host “just in case”. If it’s ever truly a concern you have you should use more vendor agnostic solutions

> people overthink the value in being able to self host “just in case”.

This. I'm guilty as charged here over the years. As I've grown older I've realized a few things. Nothing is, or ever will be perfect. Nothing lasts forever, so trying to build for what might happen in the future usually hampers what you do in the present. (IOW, don't worry about what might happen. Just build with what you have now and do the best you can. If what you build lasts until the next wave comes and makes it all obsolete, call that a win.)

If Supabase goes away at least your schema and data are still in Postgres.

What happens if Firebase goes away? Or you outgrow the NoSQL model (which you will).

What happens when you get acquired by big Java corp? They're going to toss aside your web layer and rewrite it in some old version of Java. But they will keep your data model and that's easier to do with SQL.

You do lock yourself into the software, but at least not a vendor.

Supabase developer here. True to an extent, but at least with the data, it's PostgreSQL, which you could take somewhere else. Or you could easily port it to another brand of SQL and do something else with it.

And as far as being "locked into the software", isn't that pretty much true of your entire stack? Once I choose to develop in React, I'm locked into that, right?

Reply on news.ycombinator.com