Firebase backend platforms

An exam platform I built went down for a whole day, and it was not a bug.

ImtehanHub has its own page on this site. It ran out of Firestore's free-tier read quota, and once a day's reads are gone the product is down for everybody until the counter resets.

Nobody was watching the number that decided that.

On Firestore the price of a screen is set by the query behind it rather than by the design in front of it. Every document read is billed.

A list view that pulls a collection into the browser and filters it there looks identical to one that asks the database a question, right up until the collection has grown.

Then the two diverge. One of them is a page. The other is an invoice, or a stopped product, depending on the tier you are on.

The failure is not a slow page. It is a hard stop.

So the read budget is a design constraint from the first query, not an optimisation afterwards.

That sentence decides the data model before it decides any code. A collection is shaped by the questions it has to answer, which sometimes means the same fact is stored twice so that neither copy ever has to be searched for.

Counts come from an aggregation rather than from fetching rows and measuring them. Every list read is paginated with an explicit limit, and a query without one is a bug even on a small collection.

The rules belong to the same design. A rule that checks an owner field can only be satisfied by a query that carries the matching filter, so the rule and the query are written together or neither of them works.

The constraint decides what runs where. Nothing sits on a server that has to be kept alive, and nothing depends on a vendor whose pricing can move under you. That began as a budget decision and became a design one.

What an engagement of this shape covers is settled before the first call ends.

A data model shaped by the queries it must answer. Security rules, and the probe that proves them as a non-admin. Composite indexes for every list read, because an index a query needs is otherwise discovered in production by the first person unlucky enough to run it.

Every list paginated, counts by aggregation. Authentication and account deletion end to end.

An index is not an optimisation here. It is a precondition, because a query missing the composite index it needs does not run slowly; it refuses, in front of a user, on the day the list first gets a second filter.

The probe is the part people are most surprised by. Rules are verified while signed in as an ordinary user with somebody else's data in the database, because an admin account short-circuits exactly the check you are trying to make.

Account deletion earns its own sentence. It is the flow most products describe and few finish, since deleting a user is easy and deleting everything that references them is a query plan.

Firestore is the usual home for this work, and Supabase with row-level security is the same job on different machinery. Which one a project gets is argued from the queries rather than from a preference. I am Ahsan Mahmood, and that argument gets written down where you can read it and disagree with it.

The outage above is not a cost of working this way. It is the reason the method exists, and it is why the read budget is the first conversation rather than the last.

The costs that stay are quieter. A model shaped by today's queries resists tomorrow's question, so a report nobody asked for at the start can mean a migration or a second copy of the data.

There is a smaller one, and it is more irritating. A composite index has to exist before the query that needs it runs, so a new list view is two changes rather than one.

Neither is hidden from you. They are the price of a backend whose growth does not arrive with a bill, and the alternative is paying for reads nobody budgeted for.

What is excluded here is excluded everywhere in this catalogue. Visual design as a standalone deliverable. Native iOS. Blockchain work. Copywriting and content.

Any architecture that needs a paid service in the critical path gets flagged before it is built, not after. Thirty days of bug fixes at no charge, and after that nothing is automatic.

A free tier is a quota somebody else sets, and it can be moved without asking me or you. The design keeps the number of places that change can reach as small as it can be, and every list query I have written since that outage carries an explicit limit.