IssueTracker

If I understand correctly your message, this is a feature request, namely for a different way of charging for Cloud SQL services. Would you like charges for instances and duration of use to be abolished, and then, instead, storage volume and CPU usage to become the determining factors in calculating incurred expense? Is this correct?

What do you mean by "infrequent applications"?

Why would this change in pricing methodology prove advantageous for you? A feature request needs the support of a well-motivated use-case to prove its point and convince. A detailed description, preferably in step-by-step format, would be appreciated.

> Would you like charges for instances and duration of use to be abolished, and then, instead, storage volume and CPU usage to become the determining factors in calculating incurred expense? Is this correct?

I think the per instance pricing model and the serverless pricing model will co-exist. A user should be able to choose the pricing model that fits the business requirements. Eventually users using the serverless pricing model might also want something like a reserved-capacity discount (BigQuery has a flat-rate plan *1) when they scale.

> What do you mean by "infrequent applications"?

We have a B2B application that shows strong correlation with business-hours. Our users tend to access their data during business hours but not much (less then 1/10 of peak transactional volume during day) is going on during nights. Occasionally there will be a read or write spike (maybe a user is importing or exporting large volumes of data?), but the spikes are quite unpredictable.

We are trying a new architecture with Cloud Function, Cloud Run, and BigQuery as the analytical backend. Each component scales very well without requiring extra tooling or dev-ops. From a cost-management perspective, each component scales down during nights so that we don't need to pay for the excessive resource allocation.

For example, we have internal preview (staging) environments that are short-lived and integrated with our GitHub accounts. For each pull-request, we will deploy a preview service by Cloud Run and pass it to the PM and QA team. When the pull-request is merged or closed, we have a CI/CD process that automatically cleanup the preview environment.

When we were looking for a transactional database that fits the architecture, the closest solution is Aurora Serverless by AWS (*2), but it lacks many aspect we need such as replication and federated queries from BigQuery (*3).

> Why would this change in pricing methodology prove advantageous for you?

Theoretically, we might be able to setup a monitoring system to increase / decrease the read replica. We might even try to edit the master instance capacity (if we are okay with the down-time, we aren't) to fit the workloads but it would be much easier if Cloud SQL provides them out of the box.

*1 https://cloud.google.com/bigquery/pricing#flat_rate_pricing
*2 https://aws.amazon.com/rds/aurora/serverless/
*3 https://cloud.google.com/bigquery/docs/cloud-sql-federated-queries

Engineering has been made aware of your feature request, and will address it in due course. No estimated time to implementation has been set. Meanwhile, you may follow developments in this thread.