How to Estimate Cloud Run and Firestore Monthly Cost

Estimate Cloud Run and Firestore monthly cost from workload assumptions, fixed ingress, storage, backups, logs, keys, and support. Request charges alone can understate production cost. A sound estimate labels the price date, separates provider rates from internal labor, and shows what happens when free allocations or regional requirements change.

The figures in this article are planning inputs retrieved or prepared as of 2026-08-15. They are not provider quotes. Recalculate before deployment, especially after a region, database mode, backup policy, or traffic pattern changes.

Cost surface and assumptions

Start with monthly volume and convert it into provider units. Record requests, average execution time, memory, database reads, writes, document size, stored files, backup copies, log ingestion, retention, regions, and deploy frequency. Add a burst case because daily averages can hide quotas and peak behavior.

The Cloud Run Pricing page describes request-based and resource-based charges. The Firestore Pricing page describes reads, writes, storage, indexes, backups, and related charges. These pages are the authoritative pricing inputs for the estimate, subject to change.

Cloud SQL pricing is a useful comparison when a design needs a continuously available relational database. The Cloud SQL Pricing page describes instance and storage charges. Do not include Cloud SQL in the Firestore estimate unless the architecture actually uses it.

For unit economics, read how to calculate tenant unit economics. For a regional stack comparison, read pooled regional cost modeling.

One-time work versus recurring work

Cloud usage is recurring. Migration, schema design, index review, authorization tests, backup setup, restore tests, and deployment automation are usually one-time or project-scoped. Security review, support, access review, vendor review, and incident readiness recur.

Input	Cloud Run	Firestore
Traffic	Requests, execution, CPU, memory	Reads, writes, deletes, query index use
Storage	Container and connected storage	Documents, indexes, exports, backups
Recovery	Deploy and service configuration	Backups, restore, validation, retention
Operations	Logs, monitoring, secrets, domains	Rules, indexes, access, reporting

Keep database migration and query rewrites outside the monthly number. A document model can still require new indexes, transactions, exports, reports, and server-side authorization. A successful Cloud Run deploy does not prove that Firestore preserves the current data contract.

Scenario table and calculation

Use a transparent formula.

monthly estimate =
  Cloud Run requests and resource time
  + Firestore reads, writes, storage, indexes, backups
  + ingress, logs, monitoring, keys, secrets, DNS
  + support and restore labor
  + compliance reserve

Scenario	Assumptions	Risk to validate
Low traffic	Scale-to-zero app, modest reads and writes	Fixed ingress and backups still apply
Growth	Higher request and index activity	Bursts exceed daily average
Regional	Several active regions or stacks	Fixed resources multiply

Price each scenario from the provider pages retrieved 2026-08-15. Record free allocations separately and show a post-free-allocation case. If a workload uses a feature outside the simple calculator, add a conservative reserve rather than omitting it.

Fixed costs, backups, and regional choices

Ingress, custom domains, logging, monitoring, keys, secrets, backups, and retention can dominate low traffic. Firestore storage and index choices can grow independently of request count. A restore test may be inexpensive in provider charges but still require engineering time and an approved destination.

Regional stacks multiply fixed resources. A three-region design can have more predictable geography while carrying more load balancer, database, key, log, and backup configuration. State whether regions are pooled or dedicated and include their evidence and support costs.

Cloud SQL has a clear always-on instance floor. Use it as a comparison when deciding between serverless document storage and relational operations. Do not claim that either architecture is compliant from price or service availability.

Commercial approval gate

1. Freeze workload, region, retention, and backup assumptions.
2. Run provider calculators for low, growth, and regional cases.
3. Include fixed services and post-free-tier pricing.
4. Add migration, support, restore, testing, and compliance reserve.
5. Review authorization and query proof before selecting Firestore.
6. Recalculate before production commitment.

See migration versus recurring operations and compliance reserve pricing. Stop when a calculator output is presented as a complete production quote.

Frequently asked questions

Is Cloud Run nearly free at small volume?

Request-based compute can be modest at small volume, but production cost also includes ingress, logs, storage, backups, keys, secrets, domains, monitoring, and support. Use the complete stack rather than one runtime line.

What makes Firestore cost rise?

Reads, writes, deletes, stored documents, indexes, backups, exports, bursts, and query behavior can all matter. Model the actual access patterns and label database features that fall outside a simple request estimate.

Should Cloud SQL be in the same estimate?

Only as an explicit alternative. Cloud SQL introduces an instance and operational floor. Include it when comparing architectures, but do not mix its charges into a Firestore scenario that does not use it.

References

• Google Cloud, Cloud Run Pricing, retrieved 2026-08-15: https://cloud.google.com/run/pricing
• Google Cloud, Firestore Pricing, retrieved 2026-08-15: https://cloud.google.com/firestore/pricing
• Google Cloud, Cloud SQL Pricing, retrieved 2026-08-15: https://cloud.google.com/sql/pricing