Firebase: Firestore, Auth & Serverless App Backends

Q: How does Firebase relate to Google Cloud?

Firebase projects are Google Cloud projects — Functions are Cloud Functions, Storage is GCS, and you can mix in Cloud Run or BigQuery from the same console as needs outgrow Firebase's surface.

Firebase

Firebase is Google's backend-as-a-service (BaaS) platform: a managed bundle of database (Firestore), authentication, file storage, serverless functions, and hosting that client apps talk to directly through SDKs. Instead of building and operating an API server, you write frontend code and security rules, and Firebase handles the backend.

It's a mainstay of mobile and rapid-prototyping development — realtime sync, offline support, and push notifications come essentially free — and it's the platform Supabase positions itself against with an open-source, SQL-based alternative.

TL;DR

Firebase inverts the usual architecture: clients talk to the database directly; authorization lives in server-enforced security rules, not API middleware.
Firestore is a NoSQL document database with realtime listeners and offline persistence built into the SDKs.
Firebase Auth handles email/password, phone, and OAuth sign-in (SSO providers) with a few lines of client code.
Cloud Functions cover what rules can't: triggers on data changes, scheduled jobs, third-party API calls, and anything requiring secrets.
Security rules are your only protection — default-open rules are the classic Firebase data breach.
Pricing is per operation (reads/writes/deletes), so data modeling is cost modeling.

Quick Example

Auth, a write, and a realtime listener — no server code:

And the security rules that make it safe:

Core Services

Firestore Data Modeling

Firestore is collections of documents, with subcollections for nesting:

The rules that make or break Firestore projects:

Model around your screens, not normalization. You're billed per document read, and there are no joins — each screen should be servable by one or two queries.
Denormalize deliberately. Duplicate the author's name onto each post rather than fetching the user per post; accept the double-write to keep reads cheap.
Queries only work on indexed fields (single fields are automatic; composite queries need declared indexes) and can't do OR across arbitrary fields or full-text search — for search, pair with Algolia/Typesense or Elasticsearch.
Aggregations are limited. count()/sum() exist, but complex analytics belong in BigQuery via the Firebase extension.

💡 If your data is fundamentally relational — many-to-many joins, aggregate reports, ad-hoc queries — a SQL platform like Supabase/PostgreSQL will fight you far less than Firestore denormalization.

Cloud Functions

Rules can't call Stripe or send email. Server-side logic runs in functions:

Functions are where secrets live, third-party APIs get called, and multi-document invariants get enforced. Cold starts and regional latency apply — the same serverless patterns trade-offs as AWS Lambda.

Best Practices

Treat Security Rules as Production Code

Open rules (allow read, write: if true) have caused real breaches — scanners actively probe Firebase projects. Write rules per collection, validate document shape in create/update rules, and test them with the emulator:

Develop Against the Emulator Suite

The local emulator runs Firestore, Auth, Functions, and Storage on your machine — free, fast, resettable, and CI-friendly. Never develop against the production project.

Watch Read Amplification

A chat screen that re-reads 500 messages on every visit burns budget fast. Use realtime listeners (cached snapshots cost less), paginate with limit() + cursors, and cache aggressively client-side.

Use Custom Claims for Roles

Role checks belong in the auth token, not in a document read per request:

Firebase vs Supabase

Rough guide: mobile-first apps needing offline sync and push lean Firebase; relational data, SQL skills, or exit-optionality lean Supabase. Both eliminate the custom API server for CRUD.

Common Mistakes

Default-Open Security Rules Shipped to Production

Test mode rules expire after 30 days for a reason. Locking down rules is not a launch-week task — it's part of writing each feature.

Treating Firestore Like SQL

Modeling normalized tables in Firestore leads to N reads per screen and no way to join them. Either denormalize for your access patterns or choose a SQL backend.

Unbounded Listeners

onSnapshot on a whole collection re-reads every document on first attach and bills accordingly. Always query with where + limit.

Business Logic Only on the Client

Client code can be bypassed entirely — anyone with your (public) config can call the API directly. Invariants must live in rules or functions, never solely in app code.

FAQ

Is Firebase free?

The Spark plan is generously free (Firestore quotas, auth, hosting). The Blaze pay-as-you-go plan bills per operation and is required for Cloud Functions. Costs stay low until read volume grows — then data modeling determines the bill.

Does Firebase lock me in?

Substantially — Firestore's data model, rules, and SDKs don't port. Mitigations: keep business logic in portable functions, export data regularly, and consider the trade consciously. This is the main argument for Supabase's Postgres core.

Can I use Firebase for the web, or is it mobile-only?

Fully web-capable — the JS SDK, Hosting, and App Hosting (SSR for Next.js/Angular) target web apps directly. Its offline/push strengths just matter most on mobile.

Firestore or Realtime Database?

Firestore for almost everything new — richer queries, better scaling, multi-region. The older Realtime Database survives for ultra-low-latency small-payload cases (presence, live cursors) and lower cost per tiny write.

How does Firebase relate to Google Cloud?

Firebase projects are Google Cloud projects — Functions are Cloud Functions, Storage is GCS, and you can mix in Cloud Run or BigQuery from the same console as needs outgrow Firebase's surface.