Firebase is still the “just get the app working” monster.
It gives you a pile of backend and post-launch capability in one place: auth, database, hosting, storage, functions, analytics, crash reporting, remote config, and a bunch of support systems people usually forget they need until after users show up.
Why it still matters
Firebase keeps winning whenever the real priority is:
- speed
- breadth
- mobile/web product tooling
If you want the shortest path from “I have an app idea” to “people can sign in and use it,” Firebase is still one of the strongest answers on the board.
Where the tradeoff shows up
Firebase’s great trick is that it hides a lot of complexity until you have traffic.
Then the bill, the read patterns, and the NoSQL modeling decisions start asking harder questions.
That does not make Firebase bad. It just means the product is optimized for shipping velocity first and architectural tidiness second.
When I would pick something else
I would lean away from Firebase when:
- SQL and relational modeling matter immediately
- you want more portability
- permissions should live closer to a Postgres data model than a rules system
That is where Supabase starts looking better for many web-first builders.
Further reading
 | firebase.google.com | Firebase pricing |
 | firebase.google.com | Pricing plans: Spark vs Blaze |
 | firebase.google.com | Authentication docs |
 | firebase.google.com | Cloud Firestore docs |
 | firebase.google.com | Realtime Database docs |
 | firebase.google.com | Hosting docs |
 | firebase.google.com | Cloud Functions for Firebase |
 | firebase.google.com | Cloud Storage for Firebase |
 | firebase.google.com | Local Emulator Suite |
 | firebase.google.com | App Check |
 | firebase.google.com | Crashlytics |
 | firebase.google.com | Firebase AI Logic |