If you don’t need scale then you don’t need firebase. If you need joins, don’t use firebase, etc etc.
If one insist on using a proprietary managed database I’d use Spanner.
Client has a new-ish codebase that was written by relatively inexperienced front end developers. They aren’t confident enough in the backend, and are attracted to Firebase because it lets them write everything from the front end.
Then they proceed to create the most convoluted DB model and a spaghetti backend that’s split between the front-end repo and various cloud functions.
In practical terms it’s been a nightmare every time, for me personally.
Not clear to me why the authors don’t use managed Postgres. Supabase is close enough I suppose. Personally I don’t see what you get with supabase vs an Orm and vanilla managed Postgres.
This makes development incredibly easy, especially in early stages and if you're starting out as a solo/small scale project. It is even better if you don't have an in depth knowledge about backend development/architecture and just want to build a product.
You don't get any of those benefits with a regular managed Postgres offering, at least not that I'm aware of. Supabase comes a lot closer to firebase than a regular managed postgres + ORM offering would but you also get an oepn source project that you could potentially self-host.
from what I heard self-hosting Supabase is possible, but a rather complex undertaking. There is some documentation around it, but is definitely a lot more complex than using their hosted offering is.