Azure SQL Database: Managed SQL Server in the Cloud

Q: vCore or DTU?

vCore for most cases — you choose CPU and memory independently, pricing is transparent, and you can apply Azure Hybrid Benefit (license savings). DTU bundles compute/memory/IO into simpler tiers but is less flexible. Microsoft recommends vCore for new workloads; it's the more future-proof choice.

Q: What's an elastic pool?

A way to share compute resources across many databases that individually have variable, unpredictable load — instead of provisioning peak capacity for each, they draw from a shared pool (since they rarely all peak at once). It's especially cost-effective for multi-tenant SaaS (a database per tenant). If you run many small/bursty databases, elastic pools cut cost significantly. See cloud costs.

Q: Does it support serverless / auto-scaling?

Yes — the serverless compute tier (vCore) auto-scales compute within a configured range based on load and can auto-pause during inactivity (billing only for storage while paused), resuming on the next connection. It's ideal for dev/test and intermittent workloads, avoiding the cost of an always-on provisioned database.

Azure SQL Database

Azure SQL Database is Microsoft Azure's fully managed relational database — a cloud-native version of SQL Server where Azure handles the operational burden: patching, backups, replication, high availability, and scaling. You get a SQL Server-compatible engine (same T-SQL, same tools) without managing servers, OS, or the database software itself. It's Azure's counterpart to AWS RDS and Google Cloud SQL: managed relational data for applications.

For teams building on Azure — especially those already invested in Microsoft and SQL Server — it's the default relational database. It removes the undifferentiated heavy lifting of running a database (the DBA toil of patching, backup management, failover setup) while keeping SQL Server compatibility, and adds cloud-native features like serverless auto-scaling and built-in high availability. The database fundamentals apply; this is the managed Azure service.

TL;DR

Azure SQL Database is a fully managed SQL Server — Azure handles patching, backups, replication, HA, and scaling; you focus on schema and queries.
Deployment options: Single database (isolated), Elastic pool (share resources across many databases cost-effectively), and Managed Instance (near-100% SQL Server compatibility for lift-and-shift).
Purchasing models: vCore (choose CPU/memory, more flexible, recommended) or DTU (bundled compute+storage tiers, simpler).
Serverless compute auto-scales and can pause when idle (pay only for what you use) — good for intermittent workloads.
Built-in high availability (replicas, automatic failover), automated backups with point-in-time restore, and geo-replication for DR.
Directly comparable to AWS RDS (SQL Server) and Cloud SQL — choose by cloud; deepest SQL Server integration is here.

Core Concepts

What "Managed" Removes

Running SQL Server yourself means patching the OS and database, configuring backups and testing restores, setting up replication and failover, and scaling hardware. Azure SQL Database does all of this:

Automated patching — engine and OS updates applied by Azure.
Automated backups — with point-in-time restore (rewind to any moment in the retention window) and long-term retention options.
Built-in high availability — replicas and automatic failover keep the database available through hardware failures.
Scaling — change compute/storage tiers with minimal downtime; serverless auto-scales.

You still own schema design, indexing, query performance (query optimization), and security configuration — the database logic, not the infrastructure.

Deployment Options

Elastic pools are notable for SaaS: instead of provisioning peak capacity per tenant database, many databases share a pool's resources (since they rarely peak together), cutting cost. Managed Instance maximizes compatibility for migrating existing SQL Server workloads that use instance-level features Azure SQL Database's single-database model doesn't expose.

Purchasing Models: vCore vs DTU

vCore (recommended) — you choose vCores (CPU) and memory independently, with transparent pricing and the ability to use Azure Hybrid Benefit (reuse SQL Server licenses to save). More flexible and the direction Microsoft steers you.
DTU — a bundled unit combining compute, memory, and I/O into tiers (Basic/Standard/Premium). Simpler but less flexible.

The serverless compute tier (vCore) auto-scales within a range and can auto-pause when idle, billing only for compute used — ideal for dev/test and intermittent workloads where a always-on database would waste money. See cloud costs.

Security and Networking

Azure SQL Database integrates with Microsoft Entra ID for authentication (Entra ID logins alongside or instead of SQL logins), supports managed identities so apps connect without stored credentials, and offers Transparent Data Encryption (encryption at rest), Always Encrypted (column-level), and network isolation (private endpoints in your VNet, firewall rules). Same database security discipline — keep it off the public internet, use Entra ID auth, least-privilege access.

Azure SQL Database vs AWS RDS

Azure SQL Database is specifically the managed SQL Server experience (Azure offers managed PostgreSQL and MySQL as separate services). Its distinctive strengths: deepest SQL Server compatibility and integration, elastic pools for multi-tenant SaaS, and serverless auto-pause. AWS RDS spans more engines under one service. If your workload is SQL Server / Microsoft-centric, Azure SQL Database is the natural, best-integrated home; the database concepts are identical across all managed offerings.

Common Mistakes

Provisioning Peak Capacity Always-On

Running a fixed high tier 24/7 for a workload that's mostly idle wastes money. Use the serverless tier (auto-scales, auto-pauses when idle) for intermittent workloads, elastic pools for many bursty databases, and right-size based on actual DTU/vCore utilization. See cloud costs.

Choosing DTU When vCore Fits Better

The DTU model bundles resources opaquely and lacks the flexibility (and license-reuse savings) of vCore. Microsoft recommends vCore for most new workloads — it's more transparent, flexible, and supports Azure Hybrid Benefit. Defaulting to DTU can cost more and box you in.

Single Database When Managed Instance Is Needed (or Vice Versa)

Migrating an existing SQL Server app that uses instance-level features (SQL Agent, cross-database queries, CLR) to a single database hits compatibility gaps — Managed Instance exists for that. Conversely, using Managed Instance for a simple new app is overkill. Match the deployment option to compatibility needs.

Public Endpoint and SQL-Only Auth

Exposing the database to the public internet, or relying solely on SQL logins, weakens security. Use private endpoints / VNet integration, Entra ID authentication, and managed identities for app connections. Same security discipline as any database — keep it private, use strong identity.

Ignoring Query Performance Because It's Managed

Managed infrastructure doesn't fix slow queries, missing indexes, or N+1 patterns — those are still your job. Azure provides tools (Query Performance Insight, automatic tuning) but you own schema and query design. See query optimization.

FAQ

How is Azure SQL Database different from running SQL Server on a VM?

Running SQL Server on an Azure VM (IaaS) means you manage the OS, database patching, backups, HA setup, and scaling. Azure SQL Database (PaaS) does all of that for you — automated patching, backups with point-in-time restore, built-in HA, easy scaling. Use the VM only when you need full OS/instance control the managed service doesn't allow; otherwise the managed service removes enormous operational toil.

vCore or DTU?

vCore for most cases — you choose CPU and memory independently, pricing is transparent, and you can apply Azure Hybrid Benefit (license savings). DTU bundles compute/memory/IO into simpler tiers but is less flexible. Microsoft recommends vCore for new workloads; it's the more future-proof choice.

What's an elastic pool?

A way to share compute resources across many databases that individually have variable, unpredictable load — instead of provisioning peak capacity for each, they draw from a shared pool (since they rarely all peak at once). It's especially cost-effective for multi-tenant SaaS (a database per tenant). If you run many small/bursty databases, elastic pools cut cost significantly. See cloud costs.

Azure SQL Database vs AWS RDS?

Both are managed relational databases. Azure SQL Database is specifically the managed SQL Server experience (deepest SQL Server compatibility, elastic pools, serverless auto-pause, Entra ID integration); AWS RDS supports more engines (PostgreSQL, MySQL, SQL Server, Oracle) under one service. Choose by cloud and engine — for SQL Server/Microsoft workloads, Azure SQL Database is the natural fit. Azure also offers managed PostgreSQL/MySQL separately.

Does it support serverless / auto-scaling?

Yes — the serverless compute tier (vCore) auto-scales compute within a configured range based on load and can auto-pause during inactivity (billing only for storage while paused), resuming on the next connection. It's ideal for dev/test and intermittent workloads, avoiding the cost of an always-on provisioned database.