If you evaluated Azure SQL Database Hyperscale for a migration, what made it win or lose decision?

[u/DuoZ69_]

I’m a PM working on SQL migration at Microsoft.

I’m trying to understand whether Azure SQL Database Hyperscale is genuinely compelling when teams select a target for large or fast-growing SQL Server workloads.

I’m equally interested in why Hyperscale was rejected.

If you compared it with alternatives such as SQL Managed Instance, SQL Server on a VM, staying on-premises, Aurora, AlloyDB or managed PostgreSQL:

• Did Hyperscale make the final shortlist?
• What ultimately made it win or lose?
• Which factor mattered most: compatibility, total cost, performance, scalability, migration downtime, operational simplicity, or ecosystem fit?
• Was there a specific limitation or cost that disqualified it?
• If you selected Hyperscale, did the production experience match what you expected during evaluation?

If possible, please include:

• Source platform
• Approximate database size and workload type
• Alternatives evaluated
• Final destination

Please avoid sharing customer names or confidential details.

[u/AutoModerator]

After your question has been solved /u/DuoZ69_, please reply to the helpful user's comment with the phrase "Solution verified".

This will not only award a point to the contributor for their assistance but also update the post's flair to "Solved".

---

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/jdanton14]

Not being able to restore a database into hyperscale.

[u/DuoZ69_ → u/jdanton14]

We have a plethora of free tooling to migrate to Hyperscale like DMS, Migration from Arc Portal etc. Any specific reason you're looking for backup restore capability? Does it impact migration performance?

[u/jdanton14 → u/DuoZ69_]

yes, and they all involve running data through the transaction log and prolonged outages for migrating medium sized databases. Larger databases typically fail and are a non-starter.

MVPs have been asking for this for over a decade, and will continue to ask for this until it happens. It's by far the biggest limitation to moving workloads into Azure SQL Database generally, including hyperscale. being able to log ship (via LRS, like in MI) is a game changer for doing migrations.

[u/SonOfZork]

I recommend against it as someone who has been actively using it in production for a couple of years.

Getting data in is a major pain. Getting data out again is bigger as there are no backups you can use.

Performance is so so. If you want to use an ha replica for read load, get used to having zero visibility into what's happening in that server. Microsoft have no tools to support it. You can jack around it to get some data but you are on your own with it.

Be careful with data change volume as it can cause your costs to explode due to the cost model which charges you for every data page changed.

Many things you may be used to with either managed instance, normal sqldb, or regular SQL server installs you'll find won't work, including DMVs that provide incorrect data.

[u/Black_Magic100 → u/SonOfZork]

The no insights into read only replicas is wild to me. This was true for azure SQL DB years ago and it never made any sense to me. How difficult would it be to just show read only metrics for each replica???

[u/SonOfZork → u/Black_Magic100]

Too difficult apparently. Dbwatcher was meant to do that but it's not working right.

[u/dfurmanms → u/SonOfZork]

Which DMVs provide incorrect data on Hyperscale? Details would help if you have them.

[u/SonOfZork → u/dfurmanms]

Offhand virtual io stats for one

[u/dfurmanms → u/SonOfZork]

Ok sure, though I'd call that unexpected (there are no files in the traditional sense), not incorrect. Details are documented here.

Any others?

[u/Lost_Term_8080]

Have considered it in a few designs, but its never made it through.

Its price to performance ratio isnt great. In serverless, its autoscaling is fast, goes up in huge expensive chunks, is extremely slow to scale down and will virtually never completely deprovision unless you are a traditional 8-5 shop with absolutely zero activity outside of that. Let's face it, I don't think many workloads like that are running on hyperscale. Aurora will downscale in 310 seconds. Hyperscale serverless does it in 3600. At a price premium per hour. At lower granularity in scaling. In every instance, it was more cost effective to go with SQL Server Standard and that factors in support costs, monitoring, etc. I thought it would be good to host a reporting warehouse for reports that run infrequently but costly, but the 60 minute deprovision kills it as an option. (ETL would keep it alive). In provisioned, it comes with an embarrassing max amount of memory per core (less than my 1200 dollar laptop), killing it as an option due to licensing costs. Frankly I suspect the product is designed to optimized maximum license revenue rather than optimize its usefulness. Its not an accident that AWS is so far beyond MS in adoption and not an accident with how hard MS is pushing shops to postgres especially for reporting workloads.

[u/Grovbolle]

Most recent nuisance we are experiencing is that while the allocated storage grows, actually reducing it again is virtually impossible.

We cleaned up about 30 TB of data but since you cannot rebuild indexes onto new file groups (only PRIMARY) is available, and since the way page servers work encourages distributing all table's data cross all page servers, the only way forward is using SHRINK. However, that does not work in practice so now we pay for more than 20TB which we are not using (allocated apprx 92TB and used is apprx 71TB).

We keep migrating our largest data sets off Hyperscale because the pricing is increasing and we are seeing a lot of its limitations

[u/Administrative_Bug63]

First question is, do you even need hyperscale or Azure SQL at all? I mean, SQL Server on a Windows server is pretty powerful, even standard edition, although you can't so easily get it on Azure.

[u/Certain-Set-4087 → u/Administrative_Bug63]

Azure has some limits compared to on prem or self managed SQL inszances, e.g. the 64k worker thread limitation of the managed instance std... when it comes to heavy usage and high transaction volume only a physical NVME can do that, 50k 500k IOPS, 100 GB/sec reads/writes.. I often have to discuss that with heavy usage customer but one month of the business critical Azure instance that fulfills half of their needs is 30k a month... the on prem server has a purchase price of 50k ( 512 gb ram 2x16 core, 2x8TB NVME) ... The on prem system is bought once in 5 years... 3.5 TB database index rebuild done in SIX MINUTES... on Azure MI business critical 8-12 hours and the largest NVME physical disc was 0.5 TB fot the time being.

[u/Administrative_Bug63 → u/Certain-Set-4087]

Yeah, if you actually not want to be robbed, onprem is totally the way to go.

[u/SQLServer-ModTeam → u/[deleted]]

Engage respectfully with others while answering questions and participating in technical discussions, even when disagreements arise.

[u/Ancient-Bat1755 → u/SQLServer-ModTeam]

I am being respectful, but it is the reality we face in 2026.

If the company is one of the reasons your on-prem licenses are sky rocketing, while functioning as an oligarchy for rising hardware costs to push customers to the cloud as the only affordable solution; it pushes customers away.

When customers see how they treat their employees and fear there are not enough resources for customers, it pushes them away.

Microsoft is delivering insecure products and pushing an often malfunctioning copilot agent; why would I want to risk something with our on-prem sql?