Firebase

Firebase is Google's platform for building and running mobile and web applications. It started in 2011 as a realtime database startup, was acquired by Google in 2014, and has since accumulated a broad set of services covering data storage, authentication, hosting, serverless compute, file storage, push notifications, crash reporting, analytics, remote configuration, A/B testing and app distribution. The pitch is that a small team can ship a production application without ever provisioning a server, and for a large class of products that pitch still holds.

The data layer has two options and choosing between them is the first real decision. Cloud Firestore is the current document database: collections of JSON-like documents, offline persistence and automatic sync on mobile and web clients, transactions, batched writes, composite indexes and security rules. The older Realtime Database is a single JSON tree optimised for very low latency state sharing, and it remains the right choice for some collaborative and presence use cases, but new projects should generally start with Firestore. Both are NoSQL, which means no joins and no relational integrity; you design the document structure around your access patterns, and that design work is where projects succeed or struggle.

Authentication supports email and password, phone and SMS, anonymous sign-in, and identity federation with Google, Apple, Facebook, Microsoft, X and any OpenID Connect or SAML provider. It issues tokens that Firestore rules and Cloud Functions can inspect, and it handles password reset flows, email verification and multi-factor authentication. For a team that does not want to build or maintain an identity system, this alone justifies the platform, since authentication is a common source of security incidents.

Cloud Functions run Node.js, Python and Go code in response to HTTP requests, database writes, storage events, authentication events and Cloud Pub/Sub messages. They are serverless in the strict sense: no capacity planning, pay per invocation. Cloud Run is the newer sibling for services that need containers, longer timeouts or streaming. Hosting serves static files and single-page applications on a global CDN with automatic TLS and preview channels for pre-production URLs. Cloud Storage handles user uploads with the same rules-based access control.

The quality and growth tooling is where Firebase is strongest relative to competitors. Crashlytics is the industry-standard mobile crash reporter, giving grouped stack traces, velocity alerts and user impact metrics at no cost. Analytics provides event-based reporting tied to a Google Analytics property, with audiences that feed Remote Config, A/B testing and push notification targeting. Remote Config changes app behaviour without a release. Cloud Messaging delivers push notifications to iOS, Android and the web at scale. App Distribution ships pre-release builds to testers. Performance Monitoring reports startup time, screen render time and network latency. Together these are the reason many teams stay on Firebase long after the database choice stops feeling ideal.

The Google Cloud relationship cuts both ways. Firebase services run on Google Cloud infrastructure, so you get the reliability and network of a hyperscaler, and you can graduate to BigQuery for analytics, Cloud SQL for relational data, Vertex AI for machine learning and the rest of the platform as your needs grow, without changing vendors. The downside is that billing, quotas and IAM eventually become Google Cloud problems, which are considerably more complex than the friendly Firebase console suggests, and support quality depends on the tier you pay for.

Competition comes from several directions. Supabase offers an open-source, Postgres-based backend with relational integrity and portability, and it appeals to teams that find a document model limiting. AWS Amplify covers similar ground with deeper integration into the largest cloud, at the cost of a steeper learning curve. Appwrite is an open-source self-hostable alternative. Azure Mobile Apps and Backendless serve similar niches. For pure database needs, PlanetScale, Neon and managed Postgres from any hyperscaler are alternatives. Firebase wins on maturity of mobile SDKs, breadth of adjacent services, documentation volume and the free tier; it loses on data modelling flexibility, vendor lock-in and predictability of costs at scale.

Pricing has two plans. Spark is free and includes daily limits on Firestore reads, writes and deletes, function invocations, storage and authentication, which is enough for a prototype, an internal tool or a small app with modest traffic. Blaze is pay-as-you-go per operation and per gigabyte, with monthly free allowances on top of which you are billed. Firestore pricing scales with document reads and writes rather than with data size, so an application with chatty clients can accumulate cost quickly, and a query that scans many documents is expensive even if it returns few. Functions are billed per invocation and compute time. Hosting egress is billed beyond the allowance. This model rewards careful data design and caching, and punishes naive usage. Current figures are published on the vendor pricing page and vary by region.

The limitations are significant enough to plan around. Vendor lock-in is real: there is no export path that preserves realtime sync behaviour, security rules or Cloud Functions triggers, and Firestore's query model shapes your schema in ways that are awkward to move to a relational database later. No joins means denormalisation, and denormalised data is harder to keep consistent. Costs are difficult to forecast without historical usage, and a runaway loop in a client or a function can produce a surprising bill, so budget alerts are mandatory rather than optional. Cold starts affect functions on low traffic. The free tier's limits are per-day, which makes spiky patterns tricky. Support for complex problems requires paid Google Cloud support plans. Data residency options exist through Cloud but are less flexible than a self-hosted stack. And the platform's surface area is large enough that a small team can accidentally adopt services it does not need.

Firebase fits mobile-first consumer applications, prototypes and MVPs that need to reach users fast, internal tools, real-time collaborative features, and small teams without backend engineers. It fits products where crash reporting, analytics and push notifications are first-class requirements rather than afterthoughts. It does not fit applications with complex relational data and heavy reporting, teams with strict data portability or residency requirements, products where predictable fixed costs matter more than elastic ones, or engineering organisations that already standardise on another cloud.

In the closing comparison, choose Firebase when you are shipping a mobile app quickly and want authentication, analytics, crash reporting and push in one place with a free tier that covers the early months. Choose Supabase when your data is relational, when SQL matters, or when open source and exit options are requirements. Choose AWS Amplify or plain managed services when you are already committed to another cloud and want to avoid a second vendor. Choose a dedicated Postgres provider when the database is the product. For a consumer mobile app in the hands of a small team, Firebase remains the fastest credible route from idea to a monitored, authenticated, production application.