The Firebase bill that taught us to see

The bill nobody could explain

Every team that builds on Firestore eventually gets the same surprise: a database bill that climbs faster than usage, arriving as a single opaque number. Reads are billed per document, and a modern app performs an enormous number of them — but the invoice never says which screen, which feature, or which user drove them.

Ours crept up the way these always do. A dashboard that felt instant was quietly performing hundreds of thousands of reads a day — because every time it loaded, it re-read entire collections to render a summary. Multiply that by every open tab and every active user, and the meter never stops spinning.

The uncomfortable part was not the amount. It was that nobody could point to the cause. We could see the total. We could not see the why.

Should you throw ClickHouse at a Firestore bill?

The reflex answer to “our database costs too much” is to add a cheaper analytical database — ClickHouse, BigQuery, an OLAP store — and move the heavy reads there. We seriously evaluated it. It is the move everyone recommends.

Here is what we concluded, and it is the first real lesson: a second database does not fix a read problem — it relocates it, and adds a system you now have to keep in sync. You are still doing the expensive work; you have just built a pipeline to feed a new engine, plus the drift, the lag and the maintenance that come with it. For genuine analytics workloads an OLAP store batched off your own ledgers is the right tool. But as a fix for a runaway operational bill, ClickHouse treats the symptom. The reads that were killing us were not analytics — they were a summary screen scanning a collection it should never have touched.

Reaching for a new database before you have attributed the cost is optimising blind. You will spend weeks moving data and still not know whether you solved the actual problem.

The real problem was not the database — it was the blind spot

When we finally traced it, the villain was mundane: scan-on-read. Surfaces were reading many documents on every render to compute something that should have been a single pre-computed read. The fix, once we could see it, was almost boring — mint the value on write, read one document on read. O(1) instead of O(collection). The bill fell off a cliff.

But notice the sequence. The fix was cheap. Finding it was expensive — because Firestore gives you the total and hides the breakdown.

You cannot optimise what you cannot attribute. The bill has to be itemised before any of the advice — indexes, caching, a new database — is safe to follow.

That gap — an opaque bill with no per-cause breakdown — is not unique to us. Every Firebase developer has it. So we built the thing we wished we had had on day one.

What Buckets is

Buckets is an open-source read-cost meter for Firestore. It turns the single opaque number into an itemised bill, tagging every read with where it came from — which surface or query — and who triggered it. Instead of “your bill is high”, you get “this screen is sixty per cent of it, this background job is the expensive one, and here is what each user actually costs to serve”.

It is the smart meter for a bill that previously arrived with no breakdown. Once you can see reads by cause, the optimisation becomes obvious. The hard part was never the fix. It was the visibility.

Why we open-sourced it

We could have kept Buckets internal. We did not, for two reasons.

First, the blind spot is universal. Anyone building on Firestore hits this wall, and a meter only earns trust if you can read the source. So Buckets is open source under an MIT licence and free for life — no account required to see your own cost breakdown.

Second, it reflects how we think across the portfolio: make the invisible legible. The most expensive problems in software are not the hard ones. They are the ones you cannot see. A tool that makes cost attributable is worth more than any single optimisation, because it makes every future optimisation safe to attempt. It is the same argument that produced Crossdeck, and Buckets is where it showed up first — in the least glamorous place imaginable, a database invoice.

What changed

After Buckets, cost stopped being a quarterly surprise and became a number we could point at. Expensive surfaces got flagged the moment they appeared, not three invoices later. And the discipline it forced — know the cause before you touch the code — turned out to be the actual product of the whole episode. The savings were welcome. Being able to see was the win.