In partnership with
Before anything else: this post is Part 1 of a study.
This week I'm starting a lab in my own Azure subscription. I'll run Azure SQL Database Hyperscale side by side with other Azure SQL options, starting with Managed Instance General Purpose, under different workloads. For each one I'll measure three things: what it costs, how it performs, and how it scales when the load changes.
The lab needs time to collect real numbers, about 30 days. When it's done, I'll publish the results in Part 2, with every metric and every detail of what I found.
Today's post is the foundation: what the documentation says Hyperscale is, what it's good for, and where it doesn't fit. No code, no scripts. Just the concepts you need to decide whether it belongs in your plans.
The name scares people away
"Hyperscale" sounds like it's only for giant databases. I hear that a lot: "We're not big enough for Hyperscale."
The documentation says otherwise. Microsoft describes the Hyperscale service tier as suitable for all workload types: transactional, analytical, and the mix of both. A Hyperscale database starts at just 10 GB and grows from there, up to 128 TB.
So size is one reason to choose it. It isn't the only one, and for many teams it isn't even the main one.
How it works, in plain words
In a traditional database server, everything lives together: the engine that runs your queries, the transaction log, and the data files on disk. When you need a bigger server, the data has to come along.
Hyperscale splits those jobs apart:
Compute runs your queries. It keeps the most-used data in memory and on a fast local cache.
Page servers hold the data. Each one manages a slice of up to 128 GB, and more are added automatically as the database grows.
The log service records every change and passes it on to the page servers and the copies of the database.
Azure Storage keeps everything durable underneath.
Think of a restaurant. In the old model, the kitchen and the pantry are the same room. To get a bigger kitchen, you have to move the whole pantry. In Hyperscale, the pantry is a separate building with its own staff, and the kitchen can grow or shrink without moving a single box.
Your SOC 2, handled end to end with AI agents.
Enterprise buyers won’t put your product near their customer data without a SOC 2 report. Twenty-one state privacy laws now hold them accountable for the vendors they share data with, so their diligence lands on you.
Sprinto gets you audit ready in 14 days, across three working sessions. AI agents connect your stack, collect the evidence auditors ask for, and close the gaps as they appear. You approve, they execute.
Sprinto also answers the security questionnaires your buyers send, using the same evidence base, so security reviews stop holding up deals.
No compliance hire. No consultant. Your auditor signs off.
Why that matters, even for a small database
Here's why, starting with the point that gets the most debate when we talk about total cost. After that, most of the reasons come from one design choice: storage is separate from compute, so several things that used to depend on database size don't anymore.
No SQL Server license fee in the price. Since December 2023, Hyperscale's price doesn't include a SQL license. That's a real price advantage, but it also means Azure Hybrid Benefit doesn't apply to new Hyperscale databases. If you already own licenses, do the math both ways.
Scaling compute takes minutes, not hours. Adding or removing processing power doesn't copy any data, so it happens in about the same time whether the database is 10 GB or many terabytes.
Backups are nearly instant, and restores take minutes. They're based on storage snapshots, so they don't slow down the database while it works.
Read copies don't copy anything. You can add up to four high-availability replicas, which wait ready to take over if the primary fails and can also serve reads. You can also add up to 30 named replicas, each with its own size. A small primary can run the application while a larger named replica serves reports.
You pay for the storage you actually use. You don't pick a maximum size up front. Storage grows automatically, and the bill follows it.
Serverless is an option. Compute can scale up and down automatically with the load, billed by the second. Pausing when idle is still in preview for Hyperscale.
Where it fits beyond "big data"
Situation | Why Hyperscale helps |
|---|---|
A small app that's growing fast | Starts at 10 GB, grows without you resizing anything, and never hits a size wall |
Reports competing with the app | Named replicas serve reports on their own compute, so the app's users don't feel it |
Busy seasons and month-end | Scale up for the peak, then back down, in minutes |
Many customers, one database each | Hyperscale elastic pools let many databases share one pool of compute |
Teams that need fast copies | Copies and restores come from snapshots, in minutes instead of hours |
Apps adding AI features | The same database supports vectors, JSON and graph data, so you don't need a separate store to start |
When it's not the right choice
Hyperscale is a tier of Azure SQL Database, which works one database at a time. Some applications need more than that.
Choose Azure SQL Managed Instance when the application depends on instance-level features, like SQL Server Agent jobs, Database Mail, queries across databases, Service Broker, or CLR. Managed Instance was built for moving existing SQL Server workloads with as few changes as possible. Its limits are different: up to 100 databases per instance (500 in Next-gen General Purpose) and up to 16 TB of storage (32 TB in Next-gen General Purpose).
Choose SQL Server on an Azure virtual machine when you need the operating system itself: third-party agents installed on the server, Reporting or Analysis Services on the same machine, or full control over every setting. The trade-off is that patching, high availability and backups become your job.
The one-way door
This is the part I always make sure customers hear before they decide.
If you create a database directly in Hyperscale, you can't move it to another service tier just by changing a setting. If you convert an existing database to Hyperscale, you have 45 days to move it back to General Purpose. After that, or for a database that started in Hyperscale, the only way out is to export the data and load it into a new database.
That isn't a reason to avoid Hyperscale. It's a reason to test before you commit, and to write down why you chose it. That's exactly what last Friday's tip was about.
What I'll test in the lab
The documentation tells you what a service is designed to do. A lab tells you what it does with your kind of workload, and what it costs. Over the next 30 days or so, I'll run different workloads against Hyperscale and the other options and track:
Cost: what each option really costs per day and per month for the same work
Performance: how each one handles the same queries, reads and writes
Scale: how long it takes to scale, and what happens to the application while it does
Part 2 comes in my other newsletter, DBA: From Accidental to Pro, once the lab finishes collecting data (about 30 days). That one is the deep dive: the lab setup, the runbook, and every number I collect. Subscribe there free if you want the results the day they're out.
Your turn
What workload would you want me to test? A reporting database, a busy web app, a SaaS with many small databases? Reply to this email and tell me. I read every reply, and the best ideas will make it into the lab.
If you know someone deciding where to run their next database, forward this to them.
Prefer to listen? Two AI hosts debate this post, one for it and one skeptic, on our podcast, We The People, in Tech or Not: The Debate: listen to the episode.
How I write: every post starts from my own notes and experience. I use AI tools to help draft and edit, and I review every word before it goes out.
Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Microsoft. The author is a Microsoft employee. All technical details and product behaviors described are based on publicly available Microsoft documentation as of October 2026 and are intended to provide a high-level overview for educational and architectural planning purposes.
