You did everything right. You moved SQL Server to Azure, you paid for premium storage, you sized the VM generously. And it’s still… slow. Your users are grumbling, your dashboards look fine on paper, and you’re starting to wonder if the cloud was oversold.
Here’s the uncomfortable truth I’ve been sharing on stages this year: in Azure, you’re paying for a service, and Microsoft is only going to give you exactly what you paid for. Understand that, and the mystery of the slow “premium” server evaporates.
Two throttle points, not one
Everyone thinks about disk speed. Almost nobody thinks about the two ceilings your I/O has to clear.
Your VM has a maximum IOPS and throughput. Your managed disk has its own maximum IOPS and throughput. An I/O request has to pass through both — and Azure checks those limits every 50 milliseconds, not once a second. Blow past either ceiling and Azure doesn’t fail your transaction; it quietly adds latency to hold you inside the threshold, pushing your outstanding I/Os into the next 50 ms bucket.
That’s the whole game: performance is being traded for data integrity. Nobody sent you the memo, but that’s the deal you signed.
Know which number your workload actually cares about
Before you can fix anything, you have to speak the language. Four terms, and each one matters to a different workload:
- IOPS — completed transactions per second. The classic OLTP concern: lots and lots of small, random I/Os.
- Throughput — how much data moves per second. The data-warehouse concern: can I stream enough?
- Latency — how long a single request takes start to finish. The user-facing-app concern: quick response is everything.
- Queue depth — how many requests are outstanding right now.
Chase the wrong one and you’ll “optimize” a server that’s still slow. A log writer (synchronous, single-threaded) and a reporting query (asynchronous, parallel) hit completely different walls on the same disk.
The evolution of storage — and the new sweet spot
Azure storage has quietly evolved: Rotational/Blob → Premium → Premium SSD v2 → Ultra. Everyone reaches for Ultra “when cost is no object,” but for most SQL workloads the smart money is Premium SSD v2: billed hourly, sizable from 1 GB to 64 TiB, and it hands you a baseline of 3,000 IOPS and 125 MB/s for free, with IOPS and throughput you can dial in independently. That granularity is the part people sleep on.
And a myth worth killing: Blob storage isn’t a type of storage, it’s a mechanism. It’s really SAN-style storage sitting behind an enormous amount of the platform — storage accounts, the lakehouse, the lower tiers of Azure SQL and SQL MI, Fabric, Synapse. Every “storage” request you make is, underneath, a network request. Latency matters.
The parts I save for the room
There’s a whole second act I don’t give away in a blog post, because it’s more fun in person:
- “Evil Math” — the very subtle way tempdb IOPS, data caching, and OS caching interact so that caching stops being your friend. Pay attention to your Mbps, not just your IOPS.
- Constrained cores and VM throttling — how to provision a server with higher IOPS/throughput than its disks on purpose.
- “Double Sprinkles” — the FX‑series with local NVMe and remote-disk numbers that are frankly ridiculous (and where caching no longer applies).
- SQL MI NextGen — moving from Premium SSD v1 to v2 and picking up roughly 60% more performance for the same shape.
See it live
I’m giving “Azure Storage: You want to put WHAT where??” at Baton Rouge Day of Data on Saturday, July 18, 2026. If you’ve ever stared at a “premium” server wondering where your performance went, come find me — bring your worst storage war story. No death‑by‑bullet‑point, I promise.
Because in the end, it always comes back to the same two words: latency matters.
