An app development platform that helps you build and grow apps and games users love. Backed by Google and trusted by millions of businesses around the world.
Reviewers mostly see Firebase as a fast, practical way to get an app backend running, especially for MVPs, prototypes, and small teams that want auth, realtime sync, hosting, functions, and notifications without managing servers. Makers of Context.dev, Omi, and Slashy echo that it is simple, reliable, and easy to integrate. The main complaints are complexity as projects grow, weak fit for relational querying, sprawling docs, vendor lock-in, and surprise billing risk.
Firebase lets you go from idea to working backend in minutes. Auth, real-time database, cloud storage, hosting, analytics, it's all preconfigured and works together out of the box. For MVPs and prototypes, nothing else gets you to market faster. The real-time sync is genuinely magical for collaborative features, and the free tier is generous enough to validate ideas before spending a penny.
What needs improvement
price predictability (1)
Pricing predictability is the biggest issue, it's easy to get surprise bills if a real-time listener goes haywire or a function gets hammered. The documentation is sprawling and sometimes inconsistent between older and newer SDK versions. Vendor lock-in is real, migrating off Firebase is painful once you're deep in Firestore. And the emulator suite, while helpful, doesn't perfectly replicate production behaviour, which leads to "works locally, breaks in prod" moments.
Supabase was the main alternative, open-source, Postgres-based, and more transparent on pricing. AWS Amplify for the full AWS ecosystem. For auth specifically, Auth0 and Clerk. I ended up moving to Supabase for production work because I wanted SQL, row-level security, and predictable pricing, but Firebase is still my go-to for rapid prototyping and hackathons.
Firebase gives us reliable push notifications (FCM) across iOS, Android, and web from a single API - no per-message pricing, massive scale out of the box, and deep OS integration for delivery guarantees. For a sports
scheduling app where timely match reminders are critical, it just works.
What needs improvement
complex documentation (2)
Token management is our weak spot - stale tokens accumulate in user_push_tokens and we only clean up on send failure. No built-in delivery analytics (did the user actually see it?). FCM quotas and error codes are poorly
documented. And the Firebase Admin SDK is a heavy dependency for what's essentially just HTTP calls to FCM v1 API.
vs Alternatives
OneSignal and raw VAPID/web-push. OneSignal was tempting (great dashboard) but adds a third-party dependency sitting between us and users. Raw VAPID worked for web only - no iOS support without FCM. Firebase won on cross-platform coverage and we already use Google infrastructure.
For my use case, Firebase was a very practical backend for a content-driven product workflow. I used Firestore for a blog/CMS pipeline, where the main requirement was storing and managing structured content without building a separate backend service just for publishing. The setup is quick, the SDK experience is straightforward, and it works well when you want to move fast with a frontend-heavy product. For smaller content and SaaS workflows, that simplicity can save a lot of setup time.
What needs improvement
query flexibility (1)
Firebase is very convenient when the data model is simple, but Firestore needs more planning once querying and relationships become more complex. For content-heavy or relational workflows, I sometimes prefer a database where querying and schema relationships are more explicit. Firebase is great for speed, but it is not automatically the best fit for every backend.
I’ve worked with Supabase, MongoDB, and PostgreSQL on other products, but I didn’t do a formal database comparison for this project. Firebase was already a good fit for a lightweight content/CMS workflow where speed of setup mattered more than complex relational querying.