I would only use it for quickly prototyping something that I'm 100% sure will be trashed later. Otherwise there are just too many issues with it for anything remotely serious.
The databases are completely useless for anything other than trivial demos.
Cloud functions are plagued by cold starts and deploy usually takes minutes. These are by far the worse cloud function offering in the market right now.
Storage is fast but it is extremely overpriced.
The JS client used to be super heavy. I think they've improved that with tree shaking but still, if you're using all their services, you will end up with huge JS bundle just for the Firebase stuff.
All your app becomes deeply locked in into Firebase. It's designed so that you have to invest a huge dev effort if you want to leave. Firebase could have adopted standards like GraphQL or maybe added a PG offering like Supabase, but no.
The static hosting is probably one of the slowest options in the market. At least that was the case in 2020 when I did these benchmarks.
https://www.pierbover.com/posts/static-hosting-benchmark-202...
Honestly I could go on but just don't use Firebase.
This was a problem for us when applying a template to the schedule - templates could have over 500 appointments (so difficult to apply the template in 1 tx), and not being allowed two ranges meant we could test the appointment starts but not the end. The collection issue came up because we had appointments off of users off of orgs. It was impossible to search all the users within an org/tenant the way we set it up. Either search in 1 user or all users in all orgs.
We ditched all of firebase and I’m happy we made that decision early enough.