Firebase Developer: Firestore Architecture, Auth & Cloud Functions

The Firebase work that's actually hard

Getting data into Firestore is easy. What's hard is everything that follows: modelling documents so common screens cost a handful of reads instead of hundreds, writing security rules that hold under a real threat model, keeping Cloud Functions idempotent, and stopping the bill from compounding. That's the work I take on.

• Firestore data modelling — collection and subcollection structure, denormalisation, and aggregate documents designed around your actual read paths, not a tidy-looking ERD.
• Security rules — tenancy and role enforcement written per operation and tested, with attention to the get() and exists() calls that silently bill you a read on every request.
• Composite indexes & query design — indexes that match your queries, and query shapes that avoid the multi-range patterns Firestore charges index-entry reads for.
• Cloud Functions — idempotent triggers, retry and dead-letter handling, cold-start reduction, and background jobs that don't fire twice on the same document.
• Multi-tenancy — tenant isolation that works with Firestore's rules model rather than fighting it, including per-tenant data export and deletion.
• Billing & cost control — instrumenting where reads come from, then removing them. Usually the biggest single line item on a Firebase bill.
• Migrations — Firestore to Postgres or Supabase when the document model has stopped paying for itself, done incrementally with dual writes rather than a big-bang cutover.

Why Firebase bills surprise people

Firestore charges per document read, and the operations that generate reads are not the ones most teams watch. A listener that reconnects re-reads its whole result set. An offset of 500 bills you 500 reads to return 20 documents. A count() over a million matching documents costs about a thousand reads, so polling one counter every thirty seconds can run into tens of dollars a month on its own.

None of that is Firestore being unreasonable — it's a documented, per-operation pricing model working exactly as designed. It just punishes data models that were chosen before anyone read the pricing page. I wrote a full breakdown with current numbers in Firestore pricing at scale, including what a million documents genuinely costs and the five patterns that account for most runaway bills.

Storing a million documents in Firestore costs pennies. Reading them badly, a hundred times a day, is what costs money.

When I'd tell you to leave Firebase

Firebase is an excellent fit for mobile-first apps, realtime collaboration, and products where the document model matches the domain. I'd move you off it when you're routinely fighting the query model — needing joins, multi-field range filters, transactional reporting, or ad-hoc analytics that Firestore was never built to serve.

That migration is a real project, not a weekend, and I do it incrementally: dual-write to both stores, backfill, verify parity, cut reads over per surface, then retire the old path. If you're heading that way, the Supabase and Next.js SaaS pages describe where teams usually land.

Relevant experience

I built Database Vault, a production SaaS that performs automated backups across PostgreSQL, MySQL, MongoDB, Firebase, and Supabase. Backing up a Firestore database means reading every document in it on a schedule — which is about the most direct education in Firestore read costs, pagination, and rate limits available. That product also gave me the migration tooling I use when moving clients between engines.

Alongside that I build AI and SaaS platforms such as VenueX, so I'm assessing your Firebase setup as part of a product, not in isolation.

Getting started

If the problem is the bill, send me a screenshot of your Firebase usage breakdown and a description of your busiest screen — that's usually enough to identify the top two or three read sources before I've touched the code.

If it's a build or a migration, describe the product and where the current model is fighting you. Send me the details and I'll give you a straight assessment of whether the fix is a data model change, a rules change, or a different database.