Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2

Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2

By Kendra Little on • 7 min read

Category: azure-sql , sql-server
Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2 7 min read
Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2

Microsoft recently announced that Azure SQL Managed Instance Next-gen General Purpose (GPv2) is now generally available. GPv2 brings significant storage performance improvements over GPv1, and if you’re using GPv1, you should plan to upgrade.

But GPv2 still has the same memory-to-core ratio problem that makes Managed Instance a rough deal for running SQL Server. SQL Server is engineered to use lots of memory—it’s a rare OLTP or mixed-OLTP workload that doesn’t need significant cache for reliable performance. We’ll have a look at the pricing math.

What’s New in GPv2

GPv2 entered public preview in March 2024 and remained there for 20 months before reaching general availability. The new tier brings significant improvements over GPv1. According to the announcement:

  • Better I/O latency: Average latency drops from 5-10ms to 3-4ms
  • Higher IOPS: Maximum data IOPS increases from 30-50k to 80k
  • More storage: Maximum storage increases from 16TB to 32TB
  • More databases per instance: Up to 500 databases per instance (up from 100)
  • More vCores: Maximum vCores increases from 80 to 128
  • Memory slider: New flexible memory configuration options
  • Faster scaling: Storage and IOPS can be resized independently of compute
🔥 Note on Memory Slider: The maximum amount of memory per vCore has not increased. Azure SQL Managed Instance still maxes out at 13.6 GB per vCore for memory-optimized hardware.

Why GPv1 is a Problem

If you’ve been using Azure SQL Managed Instance General Purpose, you’ve likely experienced storage pains with GPv1. I’ve written about how Azure SQL Managed Instance storage regularly stalls for 15-60 seconds in GPv1, despite Microsoft’s documentation claiming “5-10 ms” latency.

These storage stalls cause real problems. SQL Server treats I/O requests that take longer than 15 seconds as serious errors because these stalls cause blocking, query timeouts, and cascading performance issues that last far longer than the initial stall.

GPv1 uses Azure Blob Storage for database files, which has fundamental limitations, including file size-based IOPS throttling that causes customers to have to grow files unnecessarily and makes performance management difficult and unpredictable. GPv2 uses Azure Elastic SAN for storage.

Why Features Exiting Preview Matters

Preview features come with important caveats.

Now that GPv2 is generally available, it’s backed by Microsoft’s standard SLAs. If there are outages or problems, you’re entitled to service credits. The feature is committed to long-term support, and Microsoft can’t just remove it overnight.

All Managed Instance Customers Should Consider GPv2

If you’re running Azure SQL Managed Instance GPv1, plan your upgrade to GPv2. The performance improvements are significant, and the storage architecture is fundamentally better.

It’s worth your time to plan this proactively. The November 2022 feature wave was announced in November 2022 and I’m pretty sure it didn’t finish rolling out until sometime in 2024. If you aren’t proactive about upgrades, you could be waiting a while based on that past history.

Microsoft notes that zonal redundancy isn’t included in the initial GA release but is being worked on.

If you’re using Azure SQL Managed Instance Business Critical, consider if General Purpose might meet your needs with GPv2. You may have to overprovision vCores to get the memory you need for your workload, but the pricing difference might still make sense if the performance works. See the pricing comparisons below to note the differences between Business Critical and General Purpose pricing.

You Should Still Monitor for Storage Latency Issues

Even though GPv2 uses better storage technology, you should still monitor your SQL Server error logs for storage latency errors. The underlying causes may be different from GPv1’s problems, but storage latency issues can still occur for various reasons: network problems, Azure infrastructure issues, or other factors.

I’ve written about how to find these errors in the SQL Server log. Look for messages containing “longer than 15 seconds” in your error log. Use Erik Darling’s free sp_loghunter utility to search the logs programmatically.

On GPv1, these storage latency problems went largely unresolved and undiscussed for many years. Don’t let that happen again. If you see storage latency issues on GPv2, document them and report them to Microsoft support.

Microsoft Still Needs to Provide More for Managed Instance Customers

While GPv2 is a welcome improvement, Microsoft still has work to do to compete effectively with other cloud database offerings. I’ve written about three reasons RDS SQL Server is better than Azure SQL Managed Instance, and the memory-to-core ratio issue is particularly important.

SQL Server OLTP workloads benefit enormously from having large amounts of memory to reduce physical I/O. Memory access is always dramatically faster than storage access, and SQL Server is engineered to maximize use of the buffer pool and other caches.

It’s more critical than ever that Microsoft improves their memory-to-core ratios to provide a platform suitable for cache-hungry SQL Server. The comparison is stark between SQL Server 2025 prices for Standard Edition and pricing for Managed Instance General Purpose.

SQL Server 2025 Pricing

PlatformCoresTotal MemoryMemory per CoreCost per MonthCost per Year
SQL Server 2025 Standard (one-time license)4256 GB (max for Standard)64 GB$657.50$7,890
SQL Server 2025 Enterprise (one-time license)4256 GB (can go much higher without increasing licensing cost)64 GB$2,520.50$30,246
  • Pricing source: SQL Server 2025 pricing, assumes 4 cores (2-core packs × 2)
  • Price doesn’t include hardware, staff to manage Availability Groups, or Software Assurance.

What would I need to pay to get the same amount of memory on Azure SQL Managed Instance? I’m just estimating 256 GB of memory here, not a ton for a production database. But 13.6 GB of memory per core is still the maximum available in either General Purpose or Business Critical (you must choose Memory Optimized premium-series hardware to get it).

Managed Instance Pricing to Get the Same Amount of Memory

You’d have to pay for 19 vCores to get 256GB or memory on Managed Instance. 19 vCores isn’t an option, so you’ll need to pay for 20 vCores. Here’s what the Azure Pricing calculator says for East US as of November 30, 2025:

PlatformCoresTotal MemoryMemory per CoreCost per MonthCost per Year
Managed Instance GPv2 (Next Generation General Purpose)20272 GB13.6 GB$5,051.10$60,613.20
Managed Instance Business Critical20272 GB13.6 GB$12,672.80$152,073.60

These prices vary by region. In Central US your budget needs to be bigger:

PlatformCoresTotal MemoryMemory per CoreCost per MonthCost per Year
Managed Instance GPv2 (Next Generation General Purpose)20272 GB13.6 GB$5,883.30$70,599.60
Managed Instance Business Critical20272 GB13.6 GB$14,322.60$171,871.20
  • Pricing source: Azure pricing calculator, Pay as You Go, US East region, 4 vCores Next Generation General Purpose, Premium-Series memory optimized (Hardware Type), 32GB storage minimum, no zone redundancy ($1,010.22/month)

These estimates only describe 4 cores for the one-time license workload– if you’re reading this article you’ve got way more cores than that. Is the extra recurring cost worth not buying hardware (or using a VM in the cloud where you limit the active cores you have to license) or hiring someone to manage Availability Groups? ¯\_(ツ)_/¯

In both cases, it’s possible to get better deals on pricing: either by buying from resellers or package deals in the case of on-prem, or by reserved instances and Azure credits deals in the case of cloud services.

🔥 Why am I so obsessed with memory? SQL Server has been built to leverage caching for performance. The storage speeds in GPv2 and the local SSD options for Business Critical in Azure SQL ain't that great when it comes to modern storage speeds. If you need reliable database performance, sufficient memory to reduce the amount of physical I/O you do on these systems is table stakes.

I do believe there are very strong features in Azure SQL Managed Instance and that it can be a compelling product, but it badly needs more memory per vCore. This is a major flaw that undercuts the engineering achievements of the service.

Y’all, I don’t particularly enjoy managing Windows Clusters and Availability Groups, personally. I love managed database services in the cloud. But Azure SQL Managed Instance needs to support memory configurations suitable to the product that it runs at a more reasonable price. Changes like that are what really makes SaaS database services take off.