Firestore Database
Does ZopNight manage Firestore Database?
Firestore bills per document read, write, and delete plus stored data, with no idle compute meter to schedule off. ZopNight inventories Firestore databases through Cloud Asset Inventory and attributes operation and storage spend from the BigQuery billing export, where runaway read patterns show up as line items rather than 0-cost idle time.
Rules that fire on Firestore Database
No active rule family targets Firestore Database today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
Firestore is a serverless document database billed for reads, writes, deletes, and stored data. There is no idle compute charge, but unbounded read patterns and stale data retention still add up.
Metered by the operation, not the hour
Every document read, every write, and every delete is a billable event, and stored data adds a per-GB charge on top. Nothing bills while the database is untouched, the inverse of the provisioned databases elsewhere in this directory. That inversion changes where waste hides: instead of idle capacity burning overnight, cost concentrates in how code accesses data. A query that touches 500 documents to render one screen bills 500 reads, every time, for every user, and the invoice is the only place that multiplication becomes visible.
Tracing serverless database spend to its source
ZopDev inventories Firestore databases via Cloud Asset Inventory and attributes operation and storage spend from the BigQuery billing export. Because there is no instance to resize and nothing to stop, attribution is the whole game for this type: knowing which project’s databases generate the operations is what turns an anonymous usage line into a fixable access pattern.
Access patterns that quietly multiply reads
Unbounded listeners are the classic Firestore leak: a realtime subscription on a growing collection re-reads matching documents as they churn, scaling cost with data growth rather than user count. Missing pagination is a second: fetching an entire collection to display twenty items. Retention is the third; documents written by long-dead features sit in storage indefinitely because nothing forces a cleanup, and per-GB charges compound monthly.
What cost control means without a capacity dial
Fixing Firestore spend is an engineering exercise, not an infrastructure one: tighter queries, aggregation instead of client-side counting, TTL policies or scheduled deletes for expired documents. The platform’s contribution is evidence, surfacing which databases carry the spend so the right codebase gets the attention.
Finding databases in the Firestore console
Google Cloud console → Firestore → Databases lists each database in the project with its mode and location; usage detail lives under the database’s Usage tab.