← Horacio Parisotto — Senior Full-Stack & AI Engineer

Engineering case study

How I cut Firebase costs 99.7% — from $2,353/mo to $6.49/mo

By Horacio Parisotto, Senior Full-Stack & AI Engineer · October 2026

This is a breakdown of a real production incident on Arena Scheduling, an arena-scheduling and digital-signage platform in Canada. The runaway bill came from data-loading code written by another developer; because I already knew the legacy system from the inside, having built two of its venues, the company's CEO asked me to take it on. It turned into a case study in how far a targeted query fix can go when the root cause is diagnosed correctly.

The problem

For several months, the platform had been paying about $2,353 a month in Firebase costs, with nothing in place to cap it. The cause wasn't traffic growth — it was inefficient queries loading the entire database history on every request instead of filtering by the current day. Every page load, every refresh, every client re-render was pulling the full historical dataset.

Diagnosing it

The fix started with reading the Firebase usage dashboard side by side with the actual query code, rather than guessing from behavior alone. The read volume didn't correlate with active users — it correlated with how many listeners were mounted, regardless of whether that venue actually needed live data. That mismatch was the first sign the problem was structural, not just a lack of indexes.

A related issue surfaced in the same pass: a cross-venue Firestore listener leak, where every venue was activating listeners on load — including venues that never used Firestore at all. That alone was producing 93k reads/day for data nobody was reading.

The fix

• Rewrote the core queries to fetch only current-day data instead of the full history.
• Scoped Firestore listeners to activate only for venues that actually use Firestore, eliminating the cross-venue leak.
• Shipped every change late at night, when it could not disrupt a game or an event on the live arena screens.

No caching layer, no infrastructure migration, no new dependencies — the fix was entirely in query shape and listener scope. Reads dropped from 93k/day to near zero on the affected path, and bandwidth fell from 55 GB to about 0.3 GB a day.

Result

Costs dropped 99.7%, from $2,353/mo to $6.49/mo, roughly $28,000 a year saved, with no change to what arenas saw on their screens. That fix earned a much bigger mandate: rebuilding the platform from scratch as a multi-venue system.

The broader lesson: most runaway cloud costs aren't a scaling problem, they're a query-shape problem. Before reaching for caching, sharding, or a new database, it's worth confirming that every read is actually scoped to what the UI needs — not the whole table.