SysPad › Lessons › database lessons › Firebase (Firestore)

How Firebase (Firestore) works

Google Firebase - Firestore document DB + Auth, the classic student/startup backend. Usage-priced per operation: nearly free at hobby scale, and the per-read bill grows exactly with your success.

Firebase is how a solo developer ships an app with auth, a database, and realtime sync in a weekend, for free. The catch arrives with success: Firestore bills per document, so the pricing model quietly taxes exactly the screens users love most.

What you will learn

What makes Firebase the default student/startup backend?
How does per-document billing actually count?
Why do realtime listeners and list views dominate the bill?
What are the modelling moves that cut reads 10x?

A backend in a weekend

Firebase bundles auth, the Firestore document database, storage, hosting and push, with SDKs that sync data to clients in realtime. No servers, generous free tier: the fastest zero-to-app path in the industry, which is why every hackathon runs on it.

The per-document meter

Reads cost about $0.06 per 100k documents, writes about $0.18 per 100k. The crucial word is DOCUMENTS: a query returning 50 results bills 50 reads. List views, feeds, and leaderboards multiply every page view by their length.

The 10x modelling moves

The pattern that tames it: aggregate documents. Store the leaderboard as ONE document (an array), the unread-count as a counter field, the feed page as a bundle: one read instead of fifty. Cache list results client-side, paginate hard, and keep realtime listeners narrow (a listener bills a read per changed doc delivered).

⚓ On the SysPad node, "Documents per operation" is exactly this dial: drag it from 50 toward 1 under load and watch the monthly cost line drop an order of magnitude.

When does Firebase stop being the right tool entirely?

When access patterns become relational (reporting, joins, ad-hoc queries) or read volume is huge and cache-friendly. Teams then keep Firebase Auth and realtime, and move heavy data to Postgres (Supabase, RDS, Neon). The migration pain is real, which is why modelling for aggregates early matters.

Flashcards

Your app's home feed (40 documents) is opened 1M times/month. Roughly what does that one screen cost in Firestore reads, and what is the aggregate-document fix?: 40M reads ≈ $24/month for one screen, and it scales linearly with opens. Storing each feed page as one bundled document makes it 1M reads ≈ $0.60.
A dashboard keeps a realtime listener on a collection where a batch job updates 5,000 docs every minute. Why is the bill exploding with almost no users?: Every changed document delivered to every listener bills a read: 5,000 docs x 60 min x 24h is 7.2M reads/day per listener. Narrow the listener or aggregate the batch output.
"It was free for six months, now it is $400/month and growing with signups." What property of Firestore pricing did the team experience?: Linear per-operation pricing with no plateau: free tier hides the slope, success reveals it. The response is modelling (fewer docs per op), not panic-migration.

Sources

Open the SysPad canvas · Official Firebase (Firestore) documentation