Chapter 25 · Cost Engineering, Quotas, Limits, Billing, and Capacity/Usage Forecasting
Read / Write / Delete / Index / Storage / Network / Backup / PITR Billing Dimensions and Edition Differences
Model every Firestore billing dimension explicitly across Standard and Enterprise, including index work, storage, network and recovery, before applying dated prices.
1. AtlasMart launch review: method calls are not the bill
AtlasMart is about to launch semantic product discovery, live inventory badges and order status listeners. A spreadsheet says “one page view = one Firestore read,” because the author counted SDK method calls. That model omits result-set size, index-entry reads, realtime updates, retries, index storage, cross-region/network transfer, PITR and backups. It also assumes Standard and Enterprise charge for the same primitive. They do not.
The core discipline of cost engineering is to model billable work, not source-code statements. A request can scan more work than it returns; a write can update many index entries; a listener can charge repeatedly over its lifetime; and recovery features can add storage even when application traffic is zero.
- Name the independent Standard and Enterprise billing dimensions instead of collapsing them into “operations.”
- Convert an AtlasMart workload into documents, index entries, bytes, realtime updates, storage and transfer before multiplying by prices.
- Distinguish free quota, hard limits, and paid capacity.
- Forecast backup/PITR/network costs without weakening recoverability or security.
- Keep dated prices as replaceable inputs rather than architecture constants.
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. Edition first: the billing primitive changes
| Dimension | Standard Native Core | Enterprise Native / MongoDB compatibility |
|---|---|---|
| Point/document reads |
Billed by document read; queries also can incur
index-entry reads. Current
us-central1 on-demand reference:
$0.03 / 100,000 document reads.
|
Read work is billed in Read Units: data processed in 4 KiB tranches, with a minimum read-unit cost per read operation. Query scans can read index/document bytes beyond returned bytes. |
| Writes |
Each create/update counts as a document write; current
us-central1 reference:
$0.09 / 100,000 writes. Index-entry
writes are not a separate operations SKU, but index
storage still costs.
|
Writes consume Write Units in 1 KiB
tranches. Document and affected index-entry bytes
contribute. Current us-central1 reference:
$0.26 / 1,000,000 WU.
|
| Deletes |
Document delete SKU; current
us-central1 reference:
$0.01 / 100,000 deletes. TTL deletes
use the delete rate and require billing.
|
Deletes are charged as Write Units for deleted document/index data; managed-delete units can have their own SKU where supported. |
| Realtime | Initial query + later document changes are billed as reads under Standard rules. |
Initial sync uses Read Units; Native realtime changes
use separate Realtime Update Units, 4
KiB tranches. Current
us-central1 reference:
$0.30 / 1,000,000.
|
| Indexes | Queries can incur index-entry read charges; automatic/composite indexes consume storage. | Indexes are optional; scans can replace indexes, but may increase read units/latency. Creating/updating/deleting index entries consumes WU. |
| Storage/network/recovery | Data + index storage, egress, PITR, backup storage and restore/clone operations are separate dimensions. | Same categories exist but unit prices and storage model differ; never transpose Standard prices. |
A cheaper unit price is not a cheaper architecture by itself. Compare the work generated by the same access pattern under each edition, including index strategy and document sizes.
3. Dated price sheet: separate facts from assumptions
For a reproducible example, this chapter records a tiny price-input object. It is deliberately not embedded in business logic. Replace it whenever location, currency, discounts or published SKUs change.
export const pricing = { reviewedAt: "2026-09-17", location: "us-central1", standard: { per100k: { reads: 0.03, writes: 0.09, deletes: 0.01 }, freeDaily: { reads: 50_000, writes: 20_000, deletes: 20_000 }, freeStorageGiB: 1, freeOutboundGiBPerMonth: 10 }, enterprise: { perMillion: { readUnits: 0.05, writeUnits: 0.26, realtimeUnits: 0.30 }, freeDaily: { readUnits: 50_000, writeUnits: 40_000, realtimeUnits: 50_000 }, freeStorageGiB: 1, freeOutboundGiBPerMonth: 10 }};Prices vary by location and can change. CUDs/contract pricing and billing currency can also change the effective rate. Forecast in billable units first; apply a dated price sheet second.
4. Storage, network, backup and PITR are architectural dimensions
| Dimension | Cost mechanism | AtlasMart question |
|---|---|---|
| Primary storage | Documents, field names/metadata and indexes consume GiB-hours/GiB-month equivalents. | Does denormalization reduce reads enough to justify extra document/index bytes? |
| Network | Ingress is generally free; egress depends on source/destination path and database location. | Are mobile users and backend services reading across regions unnecessarily? |
| PITR | PITR data is billed separately from primary storage and can have minimum daily billing behavior. | What RPO requires PITR, and is the retained history worth the spend? |
| Backups | Each retained backup consumes backup storage based on database size at capture. | Does daily + weekly retention match recovery policy rather than habit? |
| Restore/clone | Measured by restored/cloned data size and operation SKU. | Has the recovery drill included restore operation cost and temporary duplicate storage? |
Chapter 22 established that availability is not recoverability. Chapter 25 adds the missing economic statement: the correct cost optimization is not “turn off backups,” but “choose retention and RPO/RTO deliberately, then include them in unit economics.”
5. Mandatory local lab: build a billable-work ledger
Create a workload ledger for one synthetic AtlasMart day. The emulator supplies deterministic application counts; the ledger converts them into billing dimensions without pretending emulator traffic is invoiced.
const day = { browseSessions: 1_000, browseDocsPerSession: 24, cartMutations: 1_500, orders: 120, listenerInitialDocs: 6_000, listenerChangedDocs: 2_200, vectorQueries: 300, vectorReturnedDocs: 5, vectorIndexEntriesScanned: 1_550, avgDocBytes: 1_900, avgIndexEntryBytes: 180, avgWriteDocBytes: 2_100};// Standard: vector example follows current kNN billing batches of up to 100 entries.const standard = { documentReads: day.browseSessions * day.browseDocsPerSession + day.listenerInitialDocs + day.listenerChangedDocs + day.vectorQueries * day.vectorReturnedDocs, vectorIndexReadCharges: day.vectorQueries * Math.ceil(day.vectorIndexEntriesScanned / 100), writes: day.cartMutations + day.orders * 3,};// Enterprise: approximate dimensions, not an invoice. Use measured Query Explain bytes in cloud.const enterprise = { pointReadUnits: Math.ceil((day.browseSessions * day.browseDocsPerSession * day.avgDocBytes) / 4096), writeUnitsBeforeIndexes: Math.ceil((standard.writes * day.avgWriteDocBytes) / 1024), realtimeUnits: Math.ceil((day.listenerChangedDocs * day.avgDocBytes) / 4096)};console.log({standard, enterprise});- Run AtlasMart seed and bounded browse/cart/order/listener/vector simulations locally.
- Record counts and sampled serialized byte sizes in JSON; do not invent production scan bytes.
- Calculate Standard document/index-entry dimensions separately.
-
Calculate Enterprise RU/WU/realtime dimensions only where the
local fixture provides relevant bytes; mark scan/index bytes
as
MEASURE_IN_CLOUDunless Query Explain evidence exists. - Store price inputs in a second file so the model survives pricing changes.
The lab proves your accounting model is internally consistent and reproducible. It does not prove production latency, Enterprise query-plan bytes, actual invoice totals, regional egress, negotiated discounts, or future pricing.
6. Controlled failure: optimize the invoice by deleting resilience
A misleading proposal disables PITR, backups, App Check and Rules-dependent authorization reads to “save money.” The spreadsheet improves, but RPO/RTO and abuse exposure collapse. Cost is a constraint inside the architecture, not a license to remove required controls.
The repair is to attach every cost line to its requirement: retention period → recovery objective, dependent Rules read → authorization invariant, App Check → abuse reduction, index → required query shape. Remove work only when the requirement can be satisfied another way.
Production judgment: compare architecture envelopes, not one monthly number
For each candidate architecture, report a range: base, growth, and stress/abuse. Show the dominant cost driver and the assumption it depends on. A forecast with “$37.42/month” but no distribution, retry rate, listener lifetime, document-size range, region, retention policy or growth curve is false precision.
Knowledge check
- Why can one SDK call produce multiple billable reads?
- Why can Enterprise index design affect write cost more directly than Standard?
- Why should prices be separate from workload arithmetic?
- Why is PITR not a valid first target for cost cutting?
- What does an emulator-derived operation ledger prove?
Review the answers
1. A query can return multiple documents and can also incur index-entry reads; listeners and Rules-dependent reads add other billed work.
2. Enterprise writes bill affected document/index bytes as WU; optional index choices therefore change write units as well as read plans.
3. Billing SKUs vary by location/time/discount; the workload model should remain valid after replacing the price sheet.
4. PITR implements a recoverability requirement. Optimize retention/RPO deliberately instead of silently deleting the control.
5. It proves deterministic accounting inputs and application behavior, not managed-service capacity, exact query-plan bytes or invoice truth.
Summary and next step
This lesson established the working contract for Read/Write/Delete/Index/Storage/Network/Backup/PITR Billing Dimensions and Edition Differences. Keep its edition/mode assumptions, trust boundary, verification evidence, and operational constraints explicit when reusing the pattern.
Next, continue to Listener and Query Read Amplification, Index Entry Reads, Aggregations, Retries, and Hidden Cost Multipliers.
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.