SQL Azure vs SQL Server IaaS: Your First Big Azure Architectural Choice

Shannon Lowder

Shannon Lowder

— 3 min read

When Azure went generally available, you suddenly had two ways to run SQL Server in Microsoft's cloud. They looked similar from the outside — both gave you a SQL Server endpoint you could connect to — but the architectural implications were completely different. Getting this choice wrong in 2011 cost people months of rework. Here's the decision framework I used on every engagement.

The Two Models

SQL Azure (now Azure SQL Database) is a managed service. Microsoft runs the engine, handles patching, manages backups, and owns the underlying OS. You get a connection string and a database. You don't get OS access, SQL Server Agent, linked servers, cross-database queries, or most of the surface area you're used to on a full SQL Server installation. What you do get is automatic HA, built-in redundancy, and no hardware to manage.

SQL Server IaaS means you spin up an Azure Virtual Machine, install SQL Server yourself (or pick from the gallery images), and manage the whole stack: OS patching, SQL Server patching, disk configuration, backups, monitoring. You have full SQL Server capability — Agent jobs, linked servers, SSRS, the whole surface area — because it's just SQL Server running on a VM. You also have all the operational overhead that comes with that.

In 2011, the gap between these two was wider than it is today. SQL Azure had hard size limits (10 GB for the Business edition), no support for CLR, no full-text search, no Reporting Services. If your application used any of those, the decision was made for you: IaaS.

The Decision Framework

I ran through five questions on every engagement:

  1. Does your application use SQL Server Agent? Scheduled jobs, maintenance plans, alerts — anything in the Agent. SQL Azure had none of this. If yes: IaaS, or plan to migrate your jobs to Azure Scheduler (which was limited) or rewrite them.
  2. Does your application use linked servers or cross-database queries? SQL Azure had no cross-database joins in 2011. Each database was completely isolated. If yes: IaaS, or rearchitect the application.
  3. Does your application use CLR, full-text search, Service Broker, or SSRS? SQL Azure supported none of these at launch. IaaS only.
  4. What's your database size? SQL Azure Business edition was capped at 150 GB. If you were running a 500 GB warehouse: IaaS, full stop.
  5. How much operational overhead can you carry? This is the question people skip. IaaS gives you full control. It also gives you full responsibility. Patching, monitoring, disk management, HA configuration — all on you. If you don't have the capacity to manage it, the "full feature set" of IaaS is a liability, not an asset.

What SQL Azure Did Well

For applications that fit within the constraints, SQL Azure was genuinely better than IaaS in 2011. The operational story was simply cleaner: three replicas running at all times, automatic failover, point-in-time restore, no patching windows to schedule. For a 15-person company's line-of-business database, you didn't need a DBA — you needed a connection string and a backup policy.

The pricing model also favored simpler workloads. You paid for the database size tier you needed and scaled up when you outgrew it. No SQL Server Enterprise license, no VM compute costs, no storage management. For straightforward CRUD applications under the size limits: SQL Azure was the right answer.

Where IaaS Made More Sense

The cases that pushed toward IaaS were mostly about existing workloads with existing dependencies. Legacy applications written against full SQL Server feature sets — CLR stored procedures, full-text catalogs, Agent jobs for ETL — weren't going to move to SQL Azure without significant rework. The migration cost had to be part of the calculation.

I also saw a third category that people underweighted: DBA comfort. If you were supporting the environment long-term and your team knew SQL Server inside-out but had no Azure experience, IaaS was a faster path to a stable production environment. The learning curve on the managed service's limitations was real, and production wasn't the place to discover them.

The Hybrid Case

Several clients ended up running both: SQL Azure for the transactional database powering the application, SQL Server on an IaaS VM for reporting, Agent jobs, and anything that needed the full feature surface. The transactional database got the HA and operational simplicity of the managed service. The operational workloads got the full SQL Server capability. This worked, but it added a network hop and a dependency on Azure Virtual Network to connect them — plan for that latency up front.

The choice between PaaS and IaaS in the cloud is one you'll keep making as the landscape evolves. In 2011 it was especially stark because the managed service had sharp edges. Understanding those edges before you commit is the whole job. If you're working through this decision for a specific workload, I'd love to hear the details. As always, I'm here to help.

Read more