Azure SQL Database

About Azure SQL Database

Azure SQL Database is Microsoft Azure's fully managed relational database service based on the SQL Server database engine. It is designed for cloud applications that want SQL capabilities without managing the underlying operating system, database engine patching, high availability infrastructure or routine backups. Buyers can deploy individual databases or use elastic pools, and they can choose between vCore and DTU purchasing models. The right design depends on workload size, compatibility needs, usage pattern, availability requirements and how much SQL Server instance-level functionality the application expects. Pricing, scale limits and service capabilities were rechecked against Microsoft-controlled sources on September 4, 2026.

What is Azure SQL Database used for?

Azure SQL Database is used for application back ends that need a managed relational database with SQL Server compatibility at the database level. Common scenarios include SaaS products, line-of-business applications, APIs, web applications, mobile back ends, multitenant services and new cloud applications that need transactional data, indexing, stored procedures and familiar T-SQL capabilities.

Microsoft operates the database platform, applies patches and upgrades, maintains built-in availability architecture and performs automated backups. Customers still own database design, schema changes, query tuning, security configuration, access control, data governance and application behavior. The service is therefore more managed than running SQL Server on a virtual machine, but it does not remove normal database engineering responsibilities.

How do single databases and elastic pools differ?

Azure SQL Database supports single databases and elastic pools. A single database has its own assigned resources and service tier, which makes it straightforward to size and monitor one workload independently. Elastic pools let multiple databases share a defined pool of compute and storage resources, which can be useful for SaaS or business applications where many databases have different usage peaks.

Elastic pools can reduce the cost of separately overprovisioning many databases for their individual maximum demand. They also introduce shared-resource planning. Teams should monitor database minimums, maximums, pool utilization and noisy workload behavior rather than assuming a pool automatically balances cost perfectly. A consistently busy database may be easier to size as a single database, while a group of uneven databases can benefit more from shared capacity.

How do vCore and DTU purchasing models work?

Microsoft currently offers both vCore-based and DTU-based purchasing models. The vCore model exposes compute, memory and storage choices more directly and supports service tiers including General Purpose, Business Critical and Hyperscale. Microsoft's current feature comparison lists Azure SQL Database at up to 192 vCores and up to 128 TB of storage in supported configurations, with the largest storage figure associated with Hyperscale.

The DTU model bundles CPU, memory and I/O into Database Transaction Units and provides Basic, Standard and Premium service tiers. It can be simpler for smaller or established workloads that already understand DTU sizing, but it gives less transparency than the vCore model. Azure Hybrid Benefit, reservations and the database savings plan can apply to eligible vCore workloads subject to Microsoft's current terms.

What should buyers know about the current Hyperscale size numbers?

Microsoft's current technical documentation and feature comparison list Hyperscale storage up to 128 TB and compute up to 192 vCores for supported hardware configurations. However, Microsoft's public Azure SQL Database pricing page still describes Hyperscale storage as dynamically allocated up to 100 TB. Buyers should treat this as a documentation and commercial-page discrepancy rather than assuming every region, hardware family or purchasing path exposes the same maximum immediately.

For architecture planning, confirm the supported region, hardware generation, compute size and current Azure portal or API limits before committing to a design above 100 TB. The service documentation also notes that actual IOPS and latency depend on workload behavior, and the 128 TB limit should not be interpreted as a performance guarantee. Capacity, replica design, backup strategy, migration time and operational testing still matter at very large database sizes.

When should you choose serverless instead of provisioned compute?

Provisioned compute keeps a configured amount of compute available continuously and is billed on provisioned capacity. It is usually the better fit for databases with steady or substantial utilization and for workloads that cannot tolerate delays after periods of inactivity.

Serverless automatically adjusts compute within configured limits and bills compute based on actual usage. It can pause during inactivity in supported configurations, which can reduce compute cost for intermittent workloads. Buyers should test startup behavior, minimum and maximum compute settings and workload patterns before assuming serverless will always be cheaper.

What changed with automatic backup immutability in August 2026?

Microsoft made automatic backup immutability generally available for Azure SQL Database in August 2026. The feature protects up to the most recent seven days of point-in-time restore backups from deletion or modification during the protected period. This is different from simply retaining backups for a set number of days because immutability is intended to reduce the risk that a compromised administrator, malicious process or accidental action can remove the protected restore points.

This does not replace a broader recovery design. Buyers still need to choose the appropriate point-in-time retention period, backup storage redundancy and long-term retention policy. Microsoft also supports immutable long-term retention backups, which are a separate control for backups that need to remain protected for longer compliance or recovery periods.

What availability and backup capabilities are built in?

Azure SQL Database includes built-in availability and automatically handles infrastructure failures, patching and database engine maintenance. Local redundancy is the default availability approach, while supported service tiers can use zone redundancy to improve resilience to availability-zone failures. Microsoft documents zone-redundant options for supported General Purpose, Business Critical, Hyperscale and Premium configurations where regional support exists.

Automated backups are built into the service. Microsoft currently states that point-in-time restore retention is seven days by default and can be increased up to 35 days. Long-term retention can preserve full backups for up to 10 years. Backup cost depends on database size, rate of change, configured retention and redundancy. Buyers with ransomware, compliance or privileged-access concerns should evaluate backup immutability in addition to retention length.

What should teams know about change event streaming in 2026?

Azure SQL Database can publish row-level data changes for event-driven downstream processing through change event streaming. Microsoft's July 2026 documentation introduced an important protocol change: starting August 15, 2026, AMQP is deprecated as a destination protocol for change event streaming.

New stream groups must use AzureEventHubs as the destination type. Existing stream groups already configured for AMQP can continue operating until April 2027. Teams using the older AMQP setup should inventory those stream groups now and plan migration before the cutoff instead of waiting for the existing configuration to stop working. Microsoft also documents Fabric Eventstreams as a current destination option for SQL change event streaming.

What changed for Microsoft Entra authentication in 2026?

Microsoft made Microsoft Entra server principals generally available for Azure SQL Database in June 2026. This allows organizations to create server-level principals for Microsoft Entra identities, improving identity-based administration for environments that want to reduce reliance on SQL authentication.

The feature is most relevant to organizations standardizing database access around Microsoft Entra ID and central identity controls. Buyers should still design role assignments, least privilege, break-glass access and application authentication carefully because stronger identity integration does not automatically make database permissions well governed.

How does Azure SQL Database compare with Managed Instance and SQL Server on Azure VMs?

Azure SQL Database is optimized for database-level PaaS workloads and new cloud applications. Azure SQL Managed Instance is generally a better migration target when an application depends on more SQL Server instance-level features or needs near full SQL Server compatibility with a managed service. SQL Server on Azure Virtual Machines provides the most operating-system and SQL Server control, but it also leaves more patching, high availability and infrastructure work with the customer.

The choice should start with compatibility and operational responsibility. A cloud-native application that only needs database-level SQL capabilities may fit Azure SQL Database well. A legacy application with instance-scoped dependencies may fit Managed Instance better. Workloads that require full administrator access, custom agents or operating-system control may still need SQL Server on an Azure VM.

What limitations and migration tradeoffs should buyers check?

Azure SQL Database does not provide every SQL Server instance-level feature, and some T-SQL behavior or administrative workflows differ from SQL Server and Managed Instance. Migration teams should review feature compatibility, authentication, networking, collation, linked-server dependencies, SQL Agent requirements, cross-database behavior and other application assumptions before choosing the service.

Cost can also be affected by service tier, compute model, storage, backup retention, zone redundancy, data transfer and related Azure services. A database that looks inexpensive at a low development tier can become significantly more costly once production resilience and scale requirements are added. Buyers should benchmark the real workload and use current Azure pricing tools rather than estimating from one advertised configuration.

Who should choose something else?

Organizations that need almost all SQL Server instance-level functionality for a migration should compare Azure SQL Managed Instance. Teams that need full operating-system access, custom SQL Server configuration or third-party software installed alongside the database engine should compare SQL Server on Azure Virtual Machines. Applications that do not need relational transactions or SQL semantics may be better served by another Azure database or storage service.

Azure SQL Database is strongest for cloud applications that want a managed SQL Server-based relational database with built-in patching, backups and availability, while keeping database-level development and administration familiar. Buyers should choose it when reduced infrastructure management is more valuable than full instance control.