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.

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 positions Hyperscale as the recommended service tier for many new and modernizing workloads, especially when storage growth, read scale or workload elasticity matter.

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. Reserved capacity and Azure Hybrid Benefit options are associated with the vCore model, subject to eligibility and service-tier rules.

When should you choose serverless instead of provisioned compute?

Provisioned compute keeps a configured amount of compute available continuously and bills at a fixed hourly rate for that 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 per second based on usage. It can pause during inactivity in supported configurations, which can reduce compute cost for intermittent workloads. Microsoft currently supports serverless for vCore-based single databases in General Purpose and Hyperscale. Buyers should test startup behavior, minimum and maximum compute settings and workload patterns before assuming serverless will always be cheaper.

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 General Purpose, Business Critical, Hyperscale and Premium configurations where regional support exists.

Automated backups are built into the service. Microsoft currently documents weekly full backups, differential backups every 12 or 24 hours and transaction log backups approximately every 10 minutes for non-Hyperscale databases. Point-in-time restore is available within the configured retention period, and long-term retention can preserve backups for up to 10 years. Backup storage redundancy and restore planning should still be chosen according to compliance and disaster-recovery requirements.

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.