Enable pausing Azure SQL DB/Azure SQL Managed Instance
Enable the ability to pause Azure SQL DB and Azure SQL Managed Instance like what is available in Azure SQL DW or VM.
Importing/exporting the data is not a viable option for most dev/test environments that need to be started/stopped quickly and easily.
Ramki Palle commented
I would be surprised if this feature is not there in their backlog. Can anyone from Microsoft comment on this?
Rick Heiges commented
I realize that costs are a concern and that our SLAs require us to do backups and have HA in order to meet those SLAs. Many Dev systems do not need automated backups or HA. But a DB from MI cannot be restored to anywhere else except for another MI. Perhaps we could offer a "Dev" MI for the GP tier without HA or automated backups (or the ability to have PITR set to 0 or 1). Automated patching would still be a value for Dev. This "Dev" MI could be used to restore a DB from a prod MI so a very similar environment for Dev. It could be lower cost because of no "extra" compute node for HA and no Backups. Thoughts?
Tristan Steele commented
A version which supports developer edition could be another possibility to reduce costs for Dev, Test use cases.
Arnold Garcia commented
I would prefer just the ability to have SQL MI to be able to throttle down when less busy during a set period (like after hours).
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?
It's about picing. While resizing sucks due to huge amount of time (2+ hours? seriously?), pausing seems to be a good alternative.
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.
Adam Chandley commented
I like it, in the interim we use ePools for cost control.
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.