It would be idea to be able to pause or suspend the Managed instance during off hours to save on cost
This is a difficult one to handle technically. However the main theme is cost savings. Are there other cost-saving options (other than pausing) that could address this concern? For example, smaller vCore Managed Instances etc.? On the other hand, implementing pausable Managed Instance can also mean that resuming them will take several hours each time. Is this a concern? Thank you.
Aaron Erickson commented
Are there any other alternatives to what has been suggested above? We require an MI for remote offices to interface/update a relatively small database, but the actual updates and usage occurs for only 30-40 hours of a week. Any suggestions or solutions to MI DBs on smaller side until they can be scaled to a greater point would be very helpful!
Ian Lazzari commented
I'd like to feedback on this...
We are considering migrating from IaaS to PaaS but need to prove the concept before we make the leap. The ability to pause the billing is needed to reduce the costs during initial testing.
Hitesh Patel commented
Isn't compute and storage separate for managed instance? If storage can still be a billed but compute is paused to save on cost? Is that a viable approach to reduce hours of startup time?
Joost Groot commented
If a lower size option is available changing to a lower size will reduce costs. But then a scheduled change would be great if it was built in. Or even better auto scale. Where you can setup basic 4cores or 8 cores and allow SQL to scale to 16, 24 or even 32 cores (if you have the funds) when it's needed.
Anthony Genovese commented
Smaller vCore MI sizes would fit our needs. Just like everyone else. Dev/QA envs. I don't mind it on overnight. I mind 8vcore as the minimum
Lamin Jobe commented
A great addition would be to have Auto-suspend and Auto-resume!
Also providing feedback...
Our use case is for dev/qa environments where we do not need them powered on when our dev team is not working. Taking several hours to resume would not be ideal unless we could schedule it to be fully resumed by a certain time in the morning (provided we aren't charged for the startup time or else the cost savings would be gone).
Yes - cost savings is the motivator, so this could be addressed via licensing as well (free dev/qa instances for MSDN subscribers and/or Enterprise customers, etc). Not sure how well smaller vCore instances would work for *this* concern, I would have to see what's possible with it. Could we automate the scale down / scale up the vCores quickly? How much cost would it save scaling them down overnight?
Phil Marshall commented
Providing feedback as requested...
The cost savings is certainly a big driver for us.
I can see how the ramp-up time from a fully cold start on a large database would be a consequence, and in those cases a different solution would be nicer. SQL Server from the ground up really wants to be "Always On", rather than "Sometimes On and Sometimes Off" (so-so, ha I love the acronym).
Being able to turn-off-and-on might still be a valid use case, particularly in pre-production environments. We might choose this and wear the consequence of a long ramp-up.
Generally, the pattern I see is that we have "busy times" and "quiet times", and we don't want to pay for capacity we don't need during the "quiet times". Adding elasticity would be an alternative solution, especially for production environments. If you can focus efforts on getting a wider range of sizes, and add online-scaling between sizes, then we can automate some very decent cost savings for ourselves.