Firebase, Supabase or Custom: Choosing an App Backend

Neither service is the cheap one, because they do not bill for the same thing. Firestore charges per document operation, so its bill is a function of how your screens read. Supabase charges for a machine and its disk, so its bill is a function of how much database you rent. That single difference decides more app budgets than any feature comparison, and almost nobody writes it down before the second invoice arrives.

We use both on client work. The way we choose has less to do with the databases than with what the app does when nobody is looking at it, and this guide is about how to answer that before you commit.

What Firestore actually counts

Firestore's published rates are small numbers, which is why they get skipped. Google Cloud's pricing page puts Standard edition at $0.03 per 100,000 document reads and $0.09 per 100,000 writes, beyond a free daily quota of 50,000 reads, 20,000 writes and 20,000 deletes for one database per project.

The ratio in that chart matters more than the prices. A write costs three times a read, which quietly punishes the standard document-store advice. You are told to denormalise for reads — copy the author's name onto every post, keep a counter, fan the record out to each view that needs it. Every one of those copies is a write, on the expensive side of the bill, and one edit upstream becomes many.

Then there are the reads you did not know you were buying. Google's own pricing documentation states each of these:

• A minimum of one document read per query, even if it returns no results. An empty search box that fires a query on every keystroke is billed like a search that found something.
• Security Rules that call exists(), get() or getAfter() are charged as additional reads — and what they guard is a declaration obligation of its own. The rule that checks whether the current user is a member of a team reads the team document — on every request it guards.
• A realtime listener is charged a read each time a document in its result set is added or updated. A live-updating list is not billed once; it is billed on every change for as long as it is on screen.
• Aggregations are charged per index entries read. A count() that touches up to 1,000 index entries bills as one read; 1,500 entries bills as two.

None of that is hidden — it is on the pricing page, in order. It is simply not what people estimate with, because estimates get built from row counts and Firestore does not charge for rows.

The cap that does not exist

Deferred cost control is where this stops being an estimating problem and becomes a risk. On the pay-as-you-go plan there is no supported way to put a ceiling on Firestore spend.

Google Cloud's budget documentation is explicit: setting an alerts-only budget "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." There is a newer mechanism that does pause services — spend cap budgets — but it is in preview, enforcement is documented as not instantaneous, and the eligible services are the Gemini API, Gemini Enterprise Agent Platform, Cloud Run and Cloud Run functions. Firestore is not on that list.

So the practical position in September 2026 is that a runaway listener, a retry loop in a background task or a genuinely successful launch weekend produces a bill you find out about from an alert. For most apps that is an acceptable risk with a low ceiling. For a client who needs to know the maximum, it is disqualifying, and it is worth saying out loud rather than discovering during an incident.

What Supabase charges instead

Supabase meters the resource, not the operation. From its pricing page:

Pro and Team include $10 a month of compute credits, with compute billed separately beyond that. The consequence is the mirror image of Firestore: your query count is nearly free and your idle time is not. A screen that runs twenty queries costs the same as one that runs two, until the database needs a bigger machine. An app with a hundred users pays for a machine sized to hold the data, whether or not anyone opens it.

One operational detail belongs in the decision rather than a footnote. Supabase states that free projects are paused after one week of inactivity. That is fine for a prototype and wrong for anything with real users, because a quiet week takes your backend offline. If the app is live, you are on Pro; price it that way from the start.

Which one your app is

The question that separates them is not what data you store. It is what your app does per second of a user's attention.

Firestore fits an app whose screens are mostly static once loaded and whose usage is spiky — a booking flow, a checkout, an internal tool used in bursts, anything where long idle periods should cost nothing. Its free daily quota genuinely covers small apps, and you never think about a server. That is a real advantage and we will not pretend otherwise.

Supabase fits an app with live views, feeds, dashboards, chat, collaborative editing, or anything where the interface keeps reading. It also fits any product with relational data that you will want to query in ways you have not thought of yet, because reporting over a document store is where these projects usually go wrong. If your team already knows SQL, the second month is much cheaper in hours as well as dollars.

A custom backend is correct when neither model fits: heavy background processing, integrations with systems you already run, data-residency rules that neither service satisfies, or a domain model that a document store makes awkward. We build those, and the honest trade is that you have taken on operations you were previously renting. Our mobile app development guide covers how that changes a project's shape, and the service page sets out how we scope it, and our cost guide covers what it does to the number.

Where we say no

Two positions we hold even when a client would rather we did not.

We do not put a client on Firestore's pay-as-you-go plan without saying that the spend cannot be capped. It is usually still the right choice; it is never a fair choice if nobody said it.

We do not ship a production app on a free plan of either service. Supabase pauses free projects after a week of inactivity, and Firestore's free quota is a single database per project with no headroom for a bad day. Both are fine for building. Neither is a place to stand when a customer is waiting.

Deciding in an afternoon

1. What does one screen cost? Count the document reads a busy screen performs, including security-rule reads and listener updates, then multiply by your expected sessions. If that number frightens you, you want the resource-priced option.
2. What happens when nobody uses the app for a week? Firestore charges nearly nothing. Supabase charges for the machine, and on the free plan pauses the project.
3. Do you need a hard ceiling on spend? If yes, Firestore's pay-as-you-go plan cannot give you one today.
4. Will you need to report on this data? Relational reporting over a document store is a rewrite waiting to happen.
5. Who is on the team? SQL is a common skill. Firestore data modelling and Security Rules are a specific one, and the second is where the expensive mistakes live.

If you would rather not run those numbers alone, send us what the app has to do and we will model both bills against your actual screens — including the case where the answer is neither, and you should be writing a backend.