Azure SQL Database Overview

Deployment options

Azure SQL comes in three flavors under the “Azure SQL” umbrella:

This page focuses on Azure SQL Database (single database and elastic pools), which is the right choice for most new applications. If you’re migrating an existing SQL Server application with features like SQL Agent or linked servers, look at SQL Managed Instance instead.

Service tiers and compute models

For Azure SQL Database, the vCore model is the clearer choice for most workloads. You pick the number of vCores and memory, and Azure charges you per hour. Within vCore, there are three compute tiers:

• Provisioned — you choose a fixed number of vCores. Resources are always available. Best for consistent, predictable workloads.
• Serverless — the database auto-scales between a minimum and maximum vCore count. It pauses after a configurable idle period and resumes automatically on the next connection. Great for development and irregular workloads.
• Hyperscale — designed for very large databases (up to 100 TB) with rapid scaling. Uses a distributed storage architecture separate from the standard Azure SQL storage system.

For most beginners and small-to-medium applications, start with Serverless (General Purpose tier, 1-4 vCores). It auto-pauses, costs almost nothing when idle, and handles moderate traffic when active.

Creating a database with Azure CLI

# Create a logical SQL server (the parent resource)
az sql server create \
  --name my-sql-server-demo \
  --resource-group my-storage-rg \
  --location eastus \
  --admin-user sqladmin \
  --admin-password "P@ssw0rd!Complex123"

# Create a database on the server (Serverless, General Purpose)
az sql db create \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --name myappdb \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 2 \
  --compute-model Serverless \
  --auto-pause-delay 60 \
  --min-capacity 0.5

# View the database
az sql db show \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --name myappdb \
  --output table

The —auto-pause-delay 60 flag pauses the database after 60 minutes of inactivity. The —min-capacity 0.5 means it scales down to half a vCore when idle but not yet paused.

Configuring firewall rules

By default, no inbound connections to the SQL server are allowed. You must add firewall rules to permit access from specific IPs or Azure services.

# Allow your current public IP
MY_IP=$(curl -s ifconfig.me)
az sql server firewall-rule create \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --name AllowMyIP \
  --start-ip-address $MY_IP \
  --end-ip-address $MY_IP

# Allow all Azure services (including Azure-hosted apps)
az sql server firewall-rule create \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --name AllowAllAzureIPs \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0

# List existing firewall rules
az sql server firewall-rule list \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --output table

The 0.0.0.0 to 0.0.0.0 range is a special Azure rule that allows all Azure-originating IP addresses. It does not allow access from the public internet — only from Azure datacenters.

Connecting and running queries

Connect using the sqlcmd command-line tool or any SQL Server-compatible client (Azure Data Studio, DBeaver, TablePlus).

# Connect using sqlcmd
sqlcmd \
  -S my-sql-server-demo.database.windows.net \
  -d myappdb \
  -U sqladmin \
  -P "P@ssw0rd!Complex123"

Once connected, run T-SQL commands:

-- Create a table
CREATE TABLE users (
    id INT IDENTITY(1,1) PRIMARY KEY,
    email NVARCHAR(255) NOT NULL UNIQUE,
    display_name NVARCHAR(100),
    created_at DATETIME2 DEFAULT GETUTCDATE()
);

-- Insert data
INSERT INTO users (email, display_name)
VALUES ('alice@example.com', 'Alice'),
       ('bob@example.com', 'Bob');

-- Query with a filter
SELECT id, email, display_name, created_at
FROM users
WHERE created_at > DATEADD(day, -7, GETUTCDATE())
ORDER BY created_at DESC;

-- Check database size
SELECT
    DB_NAME() AS database_name,
    SUM(size * 8.0 / 1024) AS size_mb
FROM sys.database_files
GROUP BY type_desc;

Automatic backups and point-in-time restore

Azure SQL Database takes automatic backups continuously — full backups weekly, differential backups every 12 hours, transaction log backups every 5-12 minutes. You can restore to any point in time within the retention period (7-35 days depending on your service tier).

# Restore to a specific point in time (creates a new database)
az sql db restore \
  --resource-group my-storage-rg \
  --server my-sql-server-demo \
  --name myappdb-restored \
  --source-database myappdb \
  --time "2026-03-18T14:30:00Z"

Point-in-time restore creates a new database — it doesn’t overwrite the original. After restoring, you can compare data between the original and restored database, then redirect your application if satisfied.