Cost & Performance Engineering

The most common reason teams call a Firebase consultant is an invoice. Firestore's pricing model — per document read, write, and delete — means cost is a direct function of data-model and listener design, and small modeling mistakes multiply into large bills at scale. The good news: the same fixes that cut cost usually cut latency too.

Read/write amplification

We instrument the app to find where reads multiply: listeners attached to whole collections when the UI shows five documents, queries re-fetching unchanged data on every navigation, fan-out writes rewriting large documents to change one field, and "just in case" real-time listeners on data that changes daily. Each amplification pattern gets a measured before/after, not a guess.

Denormalization strategy

Firestore makes you pay for joins at read time, every time. We decide — pattern by pattern — what to denormalize into projections, what to aggregate with counters or scheduled rollups, and what to leave normalized because the write-side complexity isn't worth it. Denormalization is a tradeoff, and we document each one so future engineers know why the shape is what it is.

Bundles, caching, and offline

Firestore bundles for static-ish datasets, local cache tuning for mobile clients, and CDN-served data for content that doesn't need per-user reads at all. A surprising share of Firestore bills pays for reads of data that hasn't changed since yesterday.

Budget alerting and cost observability

Billing budgets with meaningful thresholds, per-service cost breakdowns exported to BigQuery, and dashboards that show reads-per-feature instead of reads-per-project — so the next regression is caught by an alert during the week it ships, not by finance at month end.

Engagement shape

Cost work starts with measurement and ends with numbers: the bill before, the bill after, and the specific changes in between. Billed hourly, like all our work; many teams start with a Firebase audit to size the opportunity first.