Chapter 25 · Cost Engineering, Quotas, Limits, Billing, and Capacity/Usage Forecasting
Free Tier / Quotas vs Production Limits, Rate Limits, Daily Budgets, Alerts, and Abuse Controls
Separate free quota, hard limits, budgets and abuse controls so AtlasMart has operational cost guardrails rather than false capacity assumptions.
1. AtlasMart incident: “we are under the free tier, so production is safe”
A staging team sees fewer than 50,000 daily reads and concludes launch capacity is proven. That mixes three unrelated concepts: free quota is a pricing allowance, hard/configuration limits constrain data/API shapes, and throughput/hotspot behavior depends on workload distribution and scaling physics. None is a substitute for the others.
- Separate free allowance, hard limit, quota, hotspot behavior and budget alert.
- Use current Standard and Enterprise free-tier numbers without interpreting them as SLO or capacity guarantees.
- Build cost and abuse guardrails that do not weaken Rules, IAM, backups or recovery.
- Understand why ordinary Cloud Billing alert budgets are not hard spending caps.
- Create operational responses for quota/error/cost spikes before launch.
Use the Emulator Suite, a Firebase demo project, or an isolated test project for destructive, security-sensitive, billing-sensitive, migration, backup/restore, or write-heavy exercises unless the lesson explicitly marks managed verification as required. Treat shown output as expected evidence unless it is explicitly identified as captured output, and re-check current Firebase/Google Cloud edition, mode, quota, pricing, and security documentation before production execution.
AtlasMart keeps project ID
demo-atlasmart-firestore, Standard-edition Native
mode, database (default), Node.js 22+, Firebase
CLI course baseline 15.30.0, Firebase JavaScript
SDK 12.19.0, Firebase Admin Node SDK
14.4.0 (with
@google-cloud/firestore 9.1.0), Firestore
emulator 127.0.0.1:8080, Auth emulator
127.0.0.1:9099, and Emulator UI
127.0.0.1:4000. Mandatory exercises are
local/no-cost and measure application operation counts, bytes,
retry assumptions, listener events and forecast arithmetic—not
production billing or capacity. Dated concrete USD examples
use on-demand us-central1 prices observed on 17
September 2026; always re-check the official pricing page,
your billing currency/SKU and discounts before a real
decision. Enterprise examples are analytical unless you
explicitly provision a billed Enterprise database.
2. Free tier is a discount boundary
| Current free allowance | Standard | Enterprise Native |
|---|---|---|
| Storage | 1 GiB | 1 GiB |
| Reads | 50,000 document reads/day | 50,000 Read Units/day |
| Writes | 20,000 document writes/day | 40,000 Write Units/day |
| Deletes / realtime | 20,000 deletes/day | 50,000 Realtime Update Units/day (Native) |
| Outbound transfer | 10 GiB/month | 10 GiB/month |
Only one Firestore database per project receives the free tier. Standard TTL deletes, PITR, backup data, restore and clone are not free-tier features. A launch plan must assume paid usage once the product requires them.
A workload can be under daily free counts and still hotspot one document/key range, exceed a request/data-shape limit, or violate latency SLOs. Conversely, paid usage does not remove hard limits.
3. Hard limits are data-model constraints
| Example current Standard limit | Value | Why cost engineers care |
|---|---|---|
| Maximum index entries per document | 40,000 | Array/map fan-out can hit correctness limits before monthly cost becomes the issue. |
| Maximum index-entry size | 7.5 KiB | Large indexed values can make an index invalid/expensive. |
| Maximum sum of index-entry sizes per document | 8 MiB | Denormalization + composite indexes can fail as well as inflate storage. |
| Maximum indexed field value | 1,500 bytes before truncation | Long strings should often be exempted if not queried; truncation can affect query consistency. |
| Databases per project | 100 by default; support can increase | Multi-database tenancy is not an infinite-sharding plan. |
Do not memorize this table as eternal truth. The lab stores limits with a source timestamp and forces a re-check before release.
4. Budgets, alerts and the missing hard-cap assumption
Cloud Billing alert budgets can notify at thresholds and publish programmatic notifications, but an alerts-only budget does not stop Firestore usage or billing. Google Cloud now has a separate spend-cap budget feature in Preview for certain eligible services; at this review date Firestore is not in the documented eligible-service list. Therefore AtlasMart must not treat a generic budget alert as a Firestore kill switch.
{ "service": "firestore", "budgetType": "alerts-only", "thresholds": [0.50, 0.80, 1.00], "onAlert": [ "page cost owner", "compare usage by feature/tenant", "check listener/retry/abuse anomalies", "apply application-level rate limits or feature degradation if safe", "never disable authorization, backups, or audit controls as an automatic reaction" ]}5. Abuse controls belong before the invoice
| Layer | Control | Cost failure prevented |
|---|---|---|
| Client | App Check where supported + Firebase Auth + deny-by-default Rules | Unauthenticated scripted read/write abuse and forged client requests. |
| Backend | IAM least privilege, per-user/tenant rate limits, bounded pagination, request budgets | A valid credential cannot issue unbounded expensive scans. |
| Data/query | Required indexes, cursor pagination, narrow query shapes, tenant predicates | Avoids accidental broad scans/offset reads and cross-tenant cost. |
| Realtime | Lifecycle cleanup, listener caps per screen/session, reconnect telemetry | Avoids listener leaks and reconnect storms. |
| Operations | Billing export/alerts, Monitoring, Query Insights/Explain, incident runbook | Detects cost drift before monthly surprise. |
Rate limiting is an application/security mechanism, not a substitute for Firestore Security Rules or IAM. App Check is abuse reduction, not authorization. Keep those trust boundaries from Chapters 13–14 intact.
6. Mandatory local lab: free-tier fallacy and abuse scenario
const scenarios = [ {name:"normal", users:1_000, listenersPerUser:1, refreshesPerDay:2, retryRate:0.005}, {name:"listener-bug", users:1_000, listenersPerUser:12, refreshesPerDay:2, retryRate:0.005}, {name:"bot-abuse", users:25_000, listenersPerUser:0, refreshesPerDay:40, retryRate:0.02}];for (const s of scenarios) { const initialListenerReads = s.users * s.listenersPerUser * 20; const browseReads = s.users * s.refreshesPerDay * 24; console.log(s.name, {initialListenerReads, browseReads, retryAdjustedBrowse: Math.ceil(browseReads * (1+s.retryRate))});}- Compare normal and failure scenarios to the free tier. Do not stop when the allowance is exceeded; calculate paid dimensions.
- Add a feature-level application rate limit in the simulation and verify it reduces abusive work without granting access to unauthorized data.
- Create a JSON alert/runbook entry for 50/80/100% budget thresholds plus usage anomalies.
- Record that Firestore has no assumed generic hard spend cap in this design.
7. Controlled failure: “raise quota” before root cause
Inject a retry storm that triples requests while the user-visible success rate stays flat. Raising a quota merely lets the bug spend faster. The repair sequence is: identify response/error codes → trace retries → stop amplification/backpressure → validate query/index/listener behavior → only then request quota changes when legitimate demand needs them.
Production judgment: define graceful degradation by business value
If cost or quota pressure appears, AtlasMart can reduce optional semantic-search refresh frequency, defer low-priority analytics or cap admin exports. It must not silently weaken authorization, order consistency, retention obligations or recovery guarantees. Predefine which features can degrade and which invariants cannot.
Knowledge check
- Why is a free tier not a capacity test?
- What is the difference between a budget alert and a Firestore quota?
- Why can a listener bug create a cost spike without many users?
- What should happen before requesting more quota?
- Which controls must not be automatically disabled to save money?
Review the answers
1. It is a billing allowance, not a throughput/latency/hotspot guarantee.
2. A budget alert reports financial thresholds; a quota/limit constrains service/API usage or configuration.
3. One user can mount many listeners or reconnect repeatedly, multiplying initial sync/update reads.
4. Diagnose errors/retries/query/index/listener root cause and verify legitimate demand.
5. Authorization/security controls, required backups/PITR/retention and other correctness/compliance invariants.
Summary and next step
This lesson established the working contract for Free Tier/Quotas vs Production Limits, Rate Limits, Daily Budgets, Alerts, and Abuse Controls. Keep its edition/mode assumptions, trust boundary, verification evidence, and operational constraints explicit when reusing the pattern.
Next, continue to Model Cost per User/Feature/Event and Compare Denormalization, Fan-Out, Aggregation, and Retention Alternatives.
Authoritative references
- Google Cloud: Firestore Standard edition pricing — location-specific document operations, storage, PITR, backups/restores and network pricing.
- Google Cloud: Firestore Enterprise edition pricing — Read Units, Write Units, realtime updates, storage, networking, Query Explain and recovery pricing.
- Firebase: Understand Cloud Firestore billing — index-entry reads, aggregations, listeners, offsets, Rules-dependent reads and free quota.
- Firebase: Firestore usage and limits — Standard free quota and current hard/configuration limits.
- Firebase: Enterprise Native mode quotas and limits — Enterprise free-tier units and limits.
- Firebase: Compare Standard and Enterprise Native mode — billing/index/realtime differences.
- Google Cloud Billing budgets — alert budgets notify; ordinary alert budgets do not automatically cap spend.