Azure Data Storage: Managed vs Unmanaged Strategies
The first real decision in any Azure data design isn't which database to use. It's how much of the machinery underneath you want to be responsible for. Run SQL Server on a virtual machine and high availability, patching, backups, and scaling are all yours to build and keep working. Use Azure SQL Database and they arrive as platform behaviour you configure rather than construct. Everything else — cost model, operational burden, how quickly you can respond to a change in load — follows from that one choice.
Classify the data first
Before picking a service, it's worth being explicit about what you're storing. Data classifies three ways, and most organisations need all three:
- Structured data has a fixed schema — rows and columns, relational tables.
- Semi-structured data carries its own schema with it — JSON documents, key-value pairs, graph data.
- Unstructured data has no schema at all — text, images, video, audio, backups.
The classification drives the shortlist. Structured data wants a relational engine, semi-structured data wants a document or table store, unstructured data wants an object store. Getting this wrong is expensive later, because migrating between the three usually means rewriting the access layer, not just moving bytes.
Where the responsibility line falls
Unmanaged data typically means a plain storage account, or data living inside something you run yourself. A storage account has a default maximum capacity of 5 PiB, with no limit on the number of containers, blobs, file shares, tables, queues, or messages inside it. What actually constrains a busy account is throughput rather than capacity — request rate and bandwidth limits, which vary by region.
Unmanaged data hits application limits too, and this is the part people underestimate. Even on a managed VM, an application running inside it with its own file system and data formats is subject to that application's own limits. SQL Server in a VM has limits you have to manage yourself. You're layering a file system on top of a managed file system, and the underlying constraints show through regardless of how managed the VM is.
Managed data covers Azure SQL Database, Cosmos DB, Azure Managed Redis, and SQL Managed Instance. Regular VM data disks count as managed storage too.
The core difference is simply who is responsible for managing the underlying infrastructure and for delivering high availability and scalability.
What managed actually buys you
High availability
This is the one worth being precise about, because it's routinely confused with redundancy.
High availability is the intentional effort and expense of adding components designed to make a solution resilient. Simply having components that might be available isn't high availability.
Unmanaged: SQL Server in a VM means implementing HA yourself — multiple VMs, availability sets, availability zones, Traffic Manager, and the configuration to tie them together. Every one of those is a thing you build, test, and maintain.
Managed: Azure SQL Database has HA built in. Microsoft handles server reboots, patching, and hardware failures transparently, and customers aren't notified of these maintenance events — which is either reassuring or unsettling depending on your temperament, but is the deal you're making.
Scaling
Managed services offer easy scaling and autoscaling. You can schedule a database onto a higher performance tier during specific hours — 9am to 5pm on weekdays, say — and changing the scale of a managed database is a configuration change rather than a rebuild.
The equivalent on a VM is provisioning new capacity, migrating to it, and validating the result. Same outcome, different order of effort.
Threat detection
Managed services include built-in threat detection that identifies and blocks SQL injection attempts and repeated failed logins. On an unmanaged instance, that's a product you buy and integrate separately, or a gap you accept.
Auto-tuning
Azure SQL Database detects opportunities to improve performance and suggests index changes — adding a non-clustered index on a frequently filtered column such as last name, for instance, which improves query performance while keeping cost and complexity low.
SQL Server in a VM has no equivalent. Microsoft won't modify indexes in an unmanaged solution, because it isn't Microsoft's to modify. That asymmetry is easy to miss when comparing feature lists, and it compounds over time: a managed database gets quietly better at serving your actual query pattern, and an unmanaged one only improves when someone looks at it.
Three pricing units
The pricing models differ by service, and three units come up repeatedly. They're worth keeping straight because they aren't comparable to each other:
| Unit | What it measures |
|---|---|
| vCore | Virtual cores — you choose the number, billed hourly. Direct control over compute cost, and visibility into the hardware. |
| DTU | Database Transaction Unit. A composite of compute, storage, and I/O. You give up choosing CPU and memory; Microsoft defines the number such that 100 DTU is roughly twice the machine 50 DTU is. |
| RU/s | Request units per second — the Cosmos DB unit, measuring throughput rather than provisioned hardware. |
The distinction that matters: vCore and DTU price capacity you hold, while RU/s prices work you do. That difference is what makes serverless and consumption models possible on one and awkward on the other.
When unmanaged is still right
Managed isn't automatically the answer. Running the database yourself remains the right call when you need OS-level access, when you're running third-party software on the same server, when you need a specific version that PaaS doesn't offer, or when a lift-and-shift has to happen before any modernisation can. The deployment options that cover those cases — and the compatibility trade-offs between them — are covered in the post on Azure SQL deployment options.