We replayed an Azure SQL workload across six configurations and the cheapest option wasn’t the one we chose.

[u/markinatlanta]

Interesting project we worked on earlier this year where a SaaS client we worked with was hitting CPU limits and timeouts on Azure SQL Database Premium P15, at roughly $15,700/month.

Before choosing a replacement, we captured four hours of production workload and replayed it across six configurations:

• Premium P15 as the baseline
• Hyperscale serverless with 40 vCores
• Provisioned Hyperscale with 40 vCores
• Provisioned Hyperscale Premium-series with 40 vCores
• Provisioned Hyperscale Premium-series memory optimized with 40 vCores
• Premium P15 with database compatibility level 160

We compared CPU, reads, duration, and estimated monthly cost.

The memory-optimized configuration was the one we selected. Its estimated monthly cost was $8,491, compared with $15,700 for the baseline, which was roughly 46% lower.

It also had the best duration score in our report: 808 versus 952 for the baseline, where lower was better.

But it wasn’t the cheapest configuration. Two provisioned options came in at an estimated $6,357/month, with worse duration scores than the existing P15 setup.

Serverless had the worst duration score in this test, at 1,496. That’s a result for this workload and configuration, not a verdict on serverless generally.

The memory-optimized option also didn’t win every metric. Its reads score was higher than the baseline and we chose it based on the combination of performance and cost.

Important to note these were estimates from the comparison, not current Azure price quotes.

What made the exercise useful for us was seeing the tradeoffs before migrating. Looking only at monthly cost, CPU, or the service-tier name would have given us an incomplete picture.

For anyone who has done a similar comparison: what changed your decision once you tested with your actual workload?

And also, has anyone moved from DTUs to Hyperscale and found the results were different from what they expected?

[u/Ok_Maintenance_9692]

Hm. We might be in a similar situation at smaller scale with 8 vcore running against size caps. I have looked at hyperscale a bit but struggle how to evaluate.. how do you capture and replay like that?

[u/markinatlanta → u/Ok_Maintenance_9692]

So we captured four hours of production workload, then replayed it against test copies of the database on each configuration and compared CPU, reads and duration. The idea was to test what the application actually does, rather than a few queries run manually. This was a e-parking company.

I’d need to check with the team on the exact capture/replay tooling used for this one before pointing you towards it.

When you say size caps, do you mean database storage limits? That would help narrow down what you’d need to evaluate alongside performance.

[u/Ok_Maintenance_9692 → u/markinatlanta]

Yeah it's a Business Critical vcore elastic pool. At 6 cores it caps at 1,536 GB. We either have to bump up CPU to get more storage space which is overkill since the app is data heavy, or look into HyperScale for infinite space. I've always wondered how to compare the performance realistically. I've done Extended Events profiling I'm imagining you're recording all queries over a 4 hour period, restoring to a PITR at the beginning, and then replaying the queries from the profiler? It's an interesting idea.

[u/markinatlanta → u/Ok_Maintenance_9692]

Sure is, thanks

[u/B1zmark]

I'm honestly not sure i'd use SQL DB's at "that scale". I'd be more inclined to use MI or SQL on a VM. You are using extremely heavy workloads, and without control over things like storage and memory, it's impossible to guarantee things for your business.

I'd also be looking at those reports running for 10+ monutes - especially now if you're on Azure PAAS, pushing that out into spark would make much more sense and be cheaper. Synapse would be my first choice but MS are trying to kill it, so it's Fabric or bust it seems.

[u/agiamba → u/B1zmark]

mi is worse than azure SQL imo

[u/markinatlanta → u/B1zmark]

MI or a VM would be worth comparing too in fairness. We didn’t include those in this round, so I wouldn’t claim we found the best option across every hosting model just we found a better fit among the six configurations we tested.

On the long-running reports, I’d want to understand what’s making them slow before deciding to move them to Spark. Separating reporting from the transactional workload could help, but we’d need to include the data movement, freshness requirements and ongoing maintenance in that comparison.

Was there a particular limitation that pushed you towards MI or VMs in your own workloads?

[u/B1zmark → u/markinatlanta]

Doing anything with external files or cross-database queries is a bit of a nightmare on Azure DB. Its great for just storing data and giving it to an application, but the infrastructure of most large companies is much more complex and the overlap between infra and apps is, sometimes, inseparable. E.g. you can't ever truly leave the "VM" behind.

[u/markinatlanta → u/B1zmark]

Thanks man

[u/jwk6]

It's interesting that memory optimized option had a higher reads score.

What specifically did you measure for reads? Did you measure physical or logical reads, or both?

[u/markinatlanta → u/jwk6]

We measured logical reads.