Cloud  /  Azure

Microsoft Azure 26 guides · updated 2026

Practical guides to Azure compute, networking, storage, and data services — built for engineers running production workloads on Microsoft's cloud.

Azure SQL Database: Managed SQL Server PaaS With Hyperscale and Serverless Options

Azure SQL Database is a fully managed relational database service built on SQL Server. Microsoft handles every infrastructure concern — hardware, OS patching, SQL Server updates, backups, and built-in high availability — so your team focuses on schema design, query optimisation, and application logic.

It is not simply “SQL Server in the cloud.” Azure SQL Database is a cloud-native re-engineering of the SQL Server engine with capabilities that do not exist in on-premises deployments: a Hyperscale architecture that separates compute from storage, a Serverless tier that pauses the database during idle periods, and active geo-replication that enables readable secondaries in other Azure regions with sub-second lag.


Real-World Scenario

A SaaS company provides HR software to 300 business customers. Each customer has their own database (multitenant isolated model). Most databases are small (5–20 GB) and have varying activity — some are busy Monday mornings and idle on weekends. An elastic pool groups all 300 databases on shared compute (eDTUs or vCores), so the total compute budget is sized for concurrent peak across all customers rather than the theoretical sum of all individual database peaks. Monthly cost drops by 60% compared to provisioning each database independently.


Purchasing Models

Azure SQL Database offers two purchasing models:

DTU (Database Transaction Unit) Model
- Bundled CPU, memory, and I/O in fixed tiers
- Basic / Standard / Premium tiers
- Simple pricing; less flexibility
- Cannot independently scale compute and storage
vCore Model (recommended)
- Independent compute and storage scaling
- Matches on-premises SQL Server licensing model
- Azure Hybrid Benefit: use existing SQL Server licences
- Supports Hyperscale and Serverless tiers
- Provisioned: always-on vCores
- Serverless: auto-pause when idle, scale-on-demand

For new deployments, the vCore model gives more control and access to modern features like Hyperscale and Serverless.


Service Tiers Within vCore

Service Tier | Architecture | IOPS | Use Case
-----------------|----------------------|------------|---------------------------
General Purpose | Remote SSD storage | ~7,000 | Most applications
Business Critical| Local SSD, 3 replicas| ~200,000 | High IOPS, HA, read replicas
Hyperscale | Distributed storage | Millions | Very large DBs (> 4 TB)
Serverless | General Purpose arch | ~7,000 | Intermittent workloads

Business Critical keeps a three-node Always On Availability Group under the hood, with local NVMe SSDs. Failover takes < 30 seconds, and one secondary is readable (at no extra cost) for reporting queries.

Hyperscale decouples the compute tier from a distributed log and page server architecture, enabling databases up to 100 TB with near-instant backups and restore operations regardless of database size.


Hyperscale Architecture

Hyperscale Storage Architecture
---------------------------------
[Primary Compute Replica]
| \
Log Page cache
Service |
| [Page Servers 1..N]
| |
+-------->[Remote Storage (Azure Page Blobs)]
Scale-out reads:
[Primary Compute]
[Named Replica 1] \
[Named Replica 2] +-- all read from same page servers
[Named Replica 3] / (no replication lag for reads)

Key Hyperscale features:


Serverless Tier

The Serverless tier automatically pauses the database after a configurable idle period (minimum 1 hour) and resumes it on the next connection request. Billing stops on CPU when paused; you pay only for storage.

Serverless Compute Behaviour
------------------------------
08:00 AM - Developer connects -> database resumes (~30 second warm-up)
09:00 AM - Last connection closes
09:00 AM to 10:00 AM - auto-pause delay (configurable)
10:00 AM - Database pauses -> CPU billing stops
-> Storage billing continues
Cost profile:
Active hours: pay for vCores (scaled between min and max)
Paused hours: pay for storage only
Best for:
Dev/test databases
Applications with daily usage patterns (e.g., 9-5 business hours)
Databases used occasionally by internal teams

Elastic Pools

An elastic pool is a shared pool of compute (eDTUs or vCores) that multiple databases draw from simultaneously:

Elastic Pool Example
---------------------
Pool: 200 vCores total budget
Database A [||| ] 20 vCores (Monday morning peak)
Database B [ ] 0 vCores (idle)
Database C [||||||||| ] 80 vCores (batch job running)
Database D [|| ] 15 vCores (moderate load)
...
Total: 115 vCores consumed / 200 available
If Database A suddenly needs 80 vCores, it can burst
because other databases are not using their share.

Elastic pools are cost-effective when databases have uncorrelated peak times. They are a poor fit if all databases peak simultaneously (the pool must then be sized for the sum of peaks, losing the efficiency benefit).


Active Geo-Replication and Failover Groups

Active geo-replication creates up to four readable secondary databases in different Azure regions. Replication is asynchronous (typically < 2 second lag) and continuous.

Failover Groups wrap geo-replication with automatic failover and DNS-based connection redirection:

Failover Group
---------------
Primary (East US): sql-prod-server.database.windows.net
Secondary (West US): sql-dr-server.database.windows.net
Application uses: sql-prod-fg.database.windows.net (Listener)
When primary fails -> listener auto-switches to secondary
Application reconnects -> same endpoint, new region

This is the recommended pattern for business continuity: the application’s connection string never changes; only the server behind the listener changes during failover.


Key Interview Points


Best Practices