Assigned
Status Update
No update yet.
Comments
di...@google.com
Thank you for submitting this request. This feature request has been forwarded to our Engineering team so that they may investigate it. Future update(s) will be posted here.
po...@gmail.com
I have the same request
ma...@gmail.com
Looking for this feature as well
ch...@format14crm.com
I am also looking to get this feature, for Mon - Friday 9-5 LOB applications currently 2nd Gen is pricing itself out as an option, if we could get this feature it would be perfect
ph...@gmail.com
+1
mi...@getground.co.uk
+1
ca...@gmail.com
+1
pd...@g.hmc.edu
+1
ra...@gmail.com
I need this feature as well. Querries from my service only occur rarely. It's completely unreasonable to run the instance 24/7 (and charge for it). My DB was automatically migrated from first generation beginning this year and since then my bills went up significantly without receiving any extra value. Just a less flexible pricing model :(
cp...@calimerepoint.com
+1 - if your pricing calculator has n hours per day and x days per week and it's a manual shutdown it's at best disingenuous
sd...@tis-c.co.jp
+1
70...@gmail.com
+1
de...@upswinggolf.app
+1
be...@prismaticdigital.com
+1
[Deleted User] <[Deleted User]>
+1
an...@itsolver.net
+1
er...@gmail.com
+1
de...@gmail.com
+1
gz...@raptus.com
+1
ad...@vectorinstitute.ai
+1
tm...@gmail.com
Yes, please!!
sb...@gmail.com
+1
rs...@forefronttelecare.com
All I want is scale to zero -- to not pay for a database that isn't being used. You can do this, google!
ma...@moogah.com
+1
ha...@gmail.com
+1
sh...@cardinalgroup.com
+1
I have DEV-DB that I use probably few hours in a week. This feature will help to save a lot of money for our project.
I have DEV-DB that I use probably few hours in a week. This feature will help to save a lot of money for our project.
md...@meditech.com
+1
ro...@transcom.com
+1
sa...@clear-cut.co.il
+1
ya...@ikshealth.com
Scheduled Auto reboot of cloud sql is required. Team please a note of it try and incorporate the feature.
mk...@gmail.com
+1
jo...@johnlavery.com
+1
le...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
jo...@googlemail.com
+2
al...@heroseattle.com
+1
Ab...@dixonscarphone.com
+1
th...@hotmail.co.uk
+1
se...@veriskope.com
+1
da...@gmail.com
+1
ke...@gmail.com
+1
[Deleted User] <[Deleted User]>
Aurora does...! +1
re...@gmail.com
+1
Same as ra...@gmail.com
I need this feature as well. Querries from my service only occur rarely. It's completely unreasonable to run the instance 24/7 (and charge for it). My DB was automatically migrated from first generation beginning this year and since then my bills went up significantly without receiving any extra value. Just a less flexible pricing model :(
Same as ra...@gmail.com
I need this feature as well. Querries from my service only occur rarely. It's completely unreasonable to run the instance 24/7 (and charge for it). My DB was automatically migrated from first generation beginning this year and since then my bills went up significantly without receiving any extra value. Just a less flexible pricing model :(
do...@gmail.com
+1 - as stated above, for people with low network traffic requiring the database to be running 24/7 is rediculous when so many other things (thinking app engine/cloud functions/cloud run) are on demand. Even being able to run at a massively reduced state (potentially charging a tiny fee with basicaly no cpu power) then being able to do burst loads would be better than the current state.
wa...@gmail.com
+1
tr...@gmail.com
+1
lo...@gmail.com
+1
As a workaround I created a cloud function which is triggered by a scheduled job, it's described here:https://gist.github.com/lovromazgon/5074bc39b479841c83a78fcd83162eb2
As a workaround I created a cloud function which is triggered by a scheduled job, it's described here:
li...@gmail.com
this would indeed be very helpful!! Is there any way to know if they will actually release this feature?
[Deleted User] <[Deleted User]>
+1
fr...@gmail.com
AWS Aurora can do it, why you can't Google, shall we use AWS?
gh...@eosfintek.com
This functionality is avalible in AWS Aurora.
du...@chapeltonfarm.co.uk
I moved my development from AWS to Google because it looked cheaper, but that's not the case as I can't schedule my instances to stop/start. Unless this feature is introduced, I'll probably have to go back to AWS.
ak...@tcs.woolworths.com.au
+1
aa...@gmail.com
+1
hk...@hkosm.de
+1
au...@gmail.com
AWS already provides the serverless feature for RDS. With the help of this feature, RDS can start, stop & scale up/down according to the traffic. GCP should also provide this feature so that it can compete with AWS.
ke...@gmail.com
+1
Sooo, cashing in on keeping databases running with no traffic, with no concern for the energy waste. Come on, Google "Don't be evil"
Sooo, cashing in on keeping databases running with no traffic, with no concern for the energy waste. Come on, Google "Don't be evil"
[Deleted User] <[Deleted User]>
+1
m....@gmail.com
+1
lp...@gmail.com
+1
ma...@gmail.com
+1, nice one ke...@gmail.com!
vi...@vidia.in
+1
[Deleted User] <[Deleted User]>
+1
[Deleted User] <[Deleted User]>
+1
ii...@shahedahmmed.com
Amazon Aurora has auto stop feature. I may migrate from AWS to Google Cloud if Cloud SQL offers this feature.
lu...@gmail.com
It has been 3 years... any hope? AWS does this already.
ma...@innovativemedia.pl
I would like to use this
jo...@gmail.com
+1
ad...@edutechno.ca
Adding my vote to have this feature. Would be really useful for dev instances!
se...@gmail.com
+1
ac...@regaltechsupport.com
Please add this feature!!
si...@gmail.com
+1
br...@limestone-analytics.com
+1
l....@gmail.com
+1
aj...@google.com
Hi Cloud SQL Users,
While we take a look at offering this natively in Cloud SQL, there is an alternative you can consider to lower your compute costs at no-traffic times.
Cloud SQL supports on-demand stop and start calls through the Console, gcloud, and API for single primary instances.
You can combine this tool with Cloud Functions, Pub/Sub, and Cloud Scheduler to schedule your instance to stop and start and no-traffic times. Jonathan from our team has a nice tutorial blog post on how you can do this.
All the best,
Akhil
Cloud SQL Product Manager
[Deleted User] <[Deleted User]>
Yeah it's a bit ridiculous that this isn't included. It basically means everyone wanting to do a non-work or small personal project will end up using AWS
kw...@gmail.com
There might be a small caveat with the manual starting / stopping for cloud sql instances. If I'm not mistaken while the instance is switched off charges are still incurred for reserving the public ip.
For small use cases that leverage the smallest instance (db-f1-micro) the costs of keeping the ip reserved ($0.01/hr) is almost the same as keeping the instance up and running ($0.015/hr) which sort of defeats the point if the goal was cost saving.
The alternative is to use private ip, but when using with services like Cloud Run that then requires using VPC connectors that doubles the costs! I recall it requires 2 minimum instances running all the time.
As things stand switching off the instance may not save any costs, some suggestions I would make (not sure how feasible they are):
- Some from of new serverless SQL offering (like Cloud Run) charged by usage that can scale to zero
- Offer some form of "internal ip" or google managed address (e.g.
myinstnace.region.cloudsql....) so it's not necessarily public, but still accessible from cloud services using the usual auth mechanisms without the extra burden of VPC connectors- Perhaps some way to make cloud sql proxy work without the public ip requirement might also alleviate this point
Thanks!
gr...@gmail.com
It's true that for small instances switching them off does not save credits due to the public IP allocation. For me, the costs were even slightly larger. However, there's a workaround for that if you don't care about the public IP address changing, which was the case for me as my application uses a connection name along with an SQL connector instead of a static IP address. It's simple - you can just disable public IP for the time the instance is off.
Please see the attached graph of costs of my project - you can notice two changing points. The first one was when I introduced switching off the instance. As you can see - the blue area representing instance costs shrunk significantly, however, the red one appeared instead and drained all the savings. It was the cost connected with public IP address reservation. A few days later I added disabling the public IP address when the instance is off and re-enabling it when I run it and it allowed me to achieve the result I expected.
It wasn't as straightforward as it may seem to be, as for some reason I wasn't able to disable the instance and the IP address in a single request, so I ended up having 4 Cloud Scheduler tasks: two for starting up the instance, and two for disabling it. Please let me know if anybody is interested in the details, I'll post them then. It's a pity, however, that such a simple mechanism is not provided by Google and must be mitigated by having 2 Pub/Sub topics and 4 Cloud Scheduler tasks.
Please see the attached graph of costs of my project - you can notice two changing points. The first one was when I introduced switching off the instance. As you can see - the blue area representing instance costs shrunk significantly, however, the red one appeared instead and drained all the savings. It was the cost connected with public IP address reservation. A few days later I added disabling the public IP address when the instance is off and re-enabling it when I run it and it allowed me to achieve the result I expected.
It wasn't as straightforward as it may seem to be, as for some reason I wasn't able to disable the instance and the IP address in a single request, so I ended up having 4 Cloud Scheduler tasks: two for starting up the instance, and two for disabling it. Please let me know if anybody is interested in the details, I'll post them then. It's a pity, however, that such a simple mechanism is not provided by Google and must be mitigated by having 2 Pub/Sub topics and 4 Cloud Scheduler tasks.
sp...@live.de
Neon.tech PG instances also can scale down to zero on inactivity. It would be great to see this in CloudSQL too.
In one of your tech videos (https://www.youtube.com/watch?v=T5xJTPOMfe8 ) you suggest to create a separate project for each programmer to properly isolate each environment.
This would not be feasable if everyone in the team has to create a separate SQL instance, which then is idle 99.9% of the time and generates unnecessary cost.
In one of your tech videos (
This would not be feasable if everyone in the team has to create a separate SQL instance, which then is idle 99.9% of the time and generates unnecessary cost.
Description
Would like to have on-demand feature enable for second generation mysql instances.