Cloud Run and Cloud SQL Cost: Plan the Full Backend

A Cloud Run service can scale to zero, but Cloud SQL usually creates a fixed monthly baseline once an instance is running. Estimate the database instance class, storage, backups, and high availability separately from Cloud Run requests, CPU, memory, and execution time.

This distinction matters for low-traffic products. A prototype with a quiet API may still pay for an always-on database, while the same traffic on Firestore or a smaller managed option may have a lower fixed floor.

Cloud Run can start many instances during a spike, and each instance can open database connections. Without pooling or conservative maximum instances, a traffic burst can exhaust Cloud SQL connections before compute cost becomes the main problem.

Use a connection pool size that matches the database tier, set Cloud Run concurrency intentionally, and cap maximum instances when protecting the database is more important than accepting every sudden request. Include background workers and scheduled jobs in the same connection budget.

Place Cloud Run and Cloud SQL in compatible regions to reduce latency and avoid unnecessary network transfer. Add backup retention, read replicas, private networking, and cross-region traffic to the estimate when the product needs them.

Model expensive queries separately from simple CRUD. Reporting dashboards, search filters, exports, and admin workflows can increase CPU, memory, storage I/O, and response time. Compare the calculator's normal and spike cases before deciding whether Cloud SQL's fixed baseline is worth the query flexibility.