Azure SQL DatabaseAuthorCloudBrum editorial teamLast reviewed29 Oct 2026Reading time~12 minLevelBeginner to advanced

• The SQL Server engine, managedYou get current SQL Server behaviour and T-SQL, with no patching, no installation and no hardware. Compatibility levels let an older application keep its old behaviour while it still runs here.
• Serverless that pausesServerless compute scales between a minimum and maximum number of vCores, bills per second of use, and can pause when no one is connected. Storage is billed while it’s paused. It suits development databases and spiky workloads.
• Three vCore tiersGeneral Purpose is the default for most applications. Business Critical keeps local SSD storage and replicas for low latency and fast failover. Hyperscale separates compute from storage so the database can grow very large and add read replicas quickly.
• Elastic poolsSeveral databases share one pool of resources, which works well when many small databases each peak at different times, as in a multi-tenant product.
• Backups you can browse back in timeBackups run automatically, and point-in-time restore builds a new database at a moment inside the retention window (7 days by default, up to 35). Long-term retention keeps selected backups for up to ten years.
• Geo-replication and failover groupsReplicate a database to another Region and fail over by hand, or group databases so the whole set fails over together behind stable listener names.
• Security built around the databaseData is encrypted at rest by default, connections use TLS, and you can add Entra-only sign-in, private endpoints, Defender for SQL, auditing, data masking, row-level security and Always Encrypted.
• Tuning helpQuery Store records query history, and automatic tuning can add or remove indexes and force a known good plan when a new plan runs worse.

Logical server

A name and a set of settings (firewall, admins, authentication) that databases hang off. It isn’t a machine, and it holds no data itself.

Single database

One database with its own resources and its own bill.

Elastic pool

A shared allotment of resources for a group of databases on the same logical server.

vCore model

You choose the number of virtual cores and a tier, then storage separately. It’s the model that supports serverless, Hyperscale, reservations and Azure Hybrid Benefit.

DTU model

An older bundled measure of compute, memory and I/O sold as Basic, Standard and Premium. Simple to buy, harder to size.

Serverless

A vCore compute option with an automatic range and a pause delay. Paused databases bill for storage only.

Zone redundancy

Replicas spread over Availability Zones in the Region, so a zone failure doesn’t take the database down.

Active geo-replication

An asynchronous readable copy of a database in another Region that you fail over by command.

Failover group

A set of databases that fail over together, with read-write and read-only listener endpoints that keep their names.

Point-in-time restore

Creates a new database from the backups at a chosen moment. The original isn’t overwritten.

Long-term retention (LTR)

A policy that keeps weekly, monthly or yearly backups for up to ten years.

Query Store

A built-in history of queries, plans and runtime statistics that helps you see regressions.

Private endpoint

A private IP in your virtual network for the logical server, with traffic staying on Microsoft’s network.

Microsoft Entra-only authentication

A server setting that turns off SQL logins, so everyone signs in through Entra ID.

Create a serverless database in the Azure portal

1. Pick a Region and decide on private accessStart with the Region (Central India for many Indian teams) and with whether the logical server will be private, since that’s far easier to design in than to retrofit.
2. Create the databaseSearch for Azure SQL, choose SQL databases, then Create. Pick a resource group and a database name, and create a new server or choose an existing one.
3. Set authentication on the serverChoose Use Microsoft Entra-only authentication, and set an Entra user or group as the server administrator. This avoids a shared SQL admin password.
4. Choose the computeSelect General Purpose and Serverless for development or spiky load, with a minimum of 0.5 vCores and an auto-pause delay of an hour. For steady production load, pick provisioned compute instead.
5. Pick the backup redundancyChoose how the backups are stored: locally, across zones, or across Regions. Zone or geo storage costs more and can’t always be changed freely later.
6. Set the networkingOn the Networking tab choose Private endpoint, select the virtual network and subnet, and turn off public access. Add a private DNS integration so the server name resolves to the private address.
7. Check security optionsLeave transparent data encryption on, and consider enabling Microsoft Defender for SQL and auditing to a Log Analytics workspace.
8. Create users and testConnect from a machine in the network, run CREATE USER [name] FROM EXTERNAL PROVIDER for each application identity, and grant only the roles it needs.
9. Set limits and watch costsSet the maximum size, check the backup retention (7 days by default), and set a budget alert. Test a point-in-time restore to a new database.

• Size by measurement: CPU, workers, log I/O and data I/O in the portal. Add vCores or move tier when a limit is the problem, not by guessing.
• Find expensive queries in Query Store and Query Performance Insight, and fix missing indexes before scaling up.
• Turn on automatic tuning for plan correction, and review index suggestions before accepting them in production.
• Use connection pooling and keep connections short, since each tier has a worker and session ceiling.
• Build retry logic into the application for transient errors. It’s part of how this service is meant to be used.
• Use read scale-out (Business Critical and Hyperscale) or named replicas (Hyperscale) to send reporting reads away from the primary.
• Keep the application in the same Region as the database, and use failover group listeners for cross-Region setups.
• Choose Hyperscale when databases are large and restores, scale-up or replica creation must be quick.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Azure SQL Database.

• Use serverless with auto-pause for development and spiky databases, and choose the shortest pause delay that your users can tolerate.
• Check whether a database qualifies for the free offer, which gives a monthly allowance of serverless compute and storage per database.
• Put many small databases in an elastic pool instead of sizing each one for its own peak.
• Use Azure Hybrid Benefit if you own SQL Server licences with Software Assurance, and reservations for steady provisioned compute.
• Pick the tier honestly. Business Critical costs substantially more than General Purpose, so use it only when you need the latency and replicas.
• Keep short-term retention to what you need (7 days is the default) and long-term retention to compliance requirements, as backup storage beyond the free allowance bills.
• Delete restored copies, old replicas and test databases when you’re done with them.
• Right-size by checking utilisation, and drop a size or a vCore when graphs are flat.
• Choose backup storage redundancy deliberately. Zone and geo-redundant storage cost more than local.
• Label databases with owner and environment, and add budgets and alerts through Cost Management.

• Turn on Microsoft Entra-only authentication on the logical server, set an admin group, and give applications managed identities.
• Disable public network access and use a private endpoint with a private DNS zone. If you keep public access, list specific addresses only.
• Require TLS 1.2 as the minimum, and connect with encryption mandatory and server certificate validation on.
• Leave transparent data encryption on, and use customer-managed keys in Key Vault where policy requires it.
• Turn on auditing to a Log Analytics workspace or storage account, and Microsoft Defender for SQL for threat detection and vulnerability assessment.
• Grant database roles and schema permissions to application identities, and avoid db_owner for runtime access.
• Use dynamic data masking, row-level security and Always Encrypted for sensitive columns where they fit.
• Use the ledger feature for tables that need tamper-evidence.
• Apply Azure Policy to require Entra-only authentication, private access and auditing, and add resource locks to production servers.
• Review who holds the roles that can change firewall, authentication and backup settings, and use Privileged Identity Management for them.

To see who changed a server or database, read the Activity log and Azure Monitor. Azure Policy applies the rules above, Defender for Cloud reports posture, and Microsoft Purview can catalogue and classify data. Compliance reports sit in the Service Trust Portal. The split is the usual one: Microsoft runs the platform, engine patching and backups, and you are accountable for the data, the schema, the permissions, the network exposure and your recovery tests.

• Use serverless for databases that sit idle, so compute isn’t running while no one connects.
• Right-size provisioned databases, because spare vCores draw power all day.
• Delete test databases, old replicas and restored copies when they’ve done their job.
• Tune queries and indexes so the same database does more work with fewer resources.
• Keep retention to what you actually need, since every extra backup occupies storage.
• If the work doesn’t have to sit in a particular place, a Region on a cleaner grid is an option, data rules permitting.
• Emissions Impact Dashboard figures come per subscription; check what they include for databases before you cite one.

Purchase options

What you actually pay for

• Compute: vCore-hours (provisioned) or vCore-seconds (serverless), or DTUs
• Data storage, by the maximum size you set
• Backup storage beyond the free allowance, plus long-term retention
• Geo-replicas and named replicas, billed like databases
• Network egress between Regions, Defender for SQL and Log Analytics ingestion

The orders database on Azure SQL Database: a serverless General Purpose database on a private, Entra-only server, 14 days of point-in-time restore, weekly long-term backups and a failover group to a second Region. Build it from the CLI or Terraform tab. The Python and C# tabs sign in with a Microsoft Entra token over encrypted connections and insert an order, retrying the transient errors that serverless and failovers produce. Server names, the Entra administrator and the subscription are placeholders. The T-SQL samples weren’t run against a real SQL Server in my checks, so test them on a development database first.

# Names are examples; a server name must be unique across Azure.
RG=rg-orders-sql
LOCATION=centralindia
PARTNER_LOCATION=southindia
SERVER=orders-sql-001
PARTNER=orders-sql-002
ADMIN_ID=00000000-0000-0000-0000-000000000000   # object ID of the Entra group that administers the servers

az group create --name $RG --location $LOCATION

# A logical server with Entra-only sign-in, no public access and TLS 1.2 as the minimum
# (the CLI marks --enable-public-network as a preview argument, so it may print a warning)
az sql server create --resource-group $RG --name $SERVER --location $LOCATION \
  --enable-ad-only-auth --external-admin-principal-type Group \
  --external-admin-name orders-db-admins --external-admin-sid $ADMIN_ID \
  --enable-public-network false --minimal-tls-version 1.2

# A serverless General Purpose database: 0.5 to 2 vCores, pauses after an hour of silence
az sql db create --resource-group $RG --server $SERVER --name orders \
  --edition GeneralPurpose --family Gen5 --compute-model Serverless \
  --capacity 2 --min-capacity 0.5 --auto-pause-delay 60 \
  --max-size 32GB --backup-storage-redundancy Zone

# 14 days of point-in-time restore, and weekly backups kept for four weeks, monthly for a year
az sql db str-policy set --resource-group $RG --server $SERVER --name orders --retention-days 14
az sql db ltr-policy set --resource-group $RG --server $SERVER --name orders \
  --weekly-retention P4W --monthly-retention P12M --week-of-year 1

# A private endpoint for the logical server (a private DNS zone makes the normal server name resolve to it)
az network vnet create --resource-group $RG --name vnet-orders --address-prefixes 10.30.0.0/16 \
  --subnet-name snet-data --subnet-prefixes 10.30.1.0/24
SQL_ID=$(az sql server show --resource-group $RG --name $SERVER --query id --output tsv)
az network private-endpoint create --resource-group $RG --name pe-orders-sql \
  --vnet-name vnet-orders --subnet snet-data \
  --private-connection-resource-id $SQL_ID --group-id sqlServer --connection-name orders-sql
az network private-dns zone create --resource-group $RG --name privatelink.database.windows.net
az network private-dns link vnet create --resource-group $RG --zone-name privatelink.database.windows.net \
  --name orders-sql-link --virtual-network vnet-orders --registration-enabled false
az network private-endpoint dns-zone-group create --resource-group $RG --endpoint-name pe-orders-sql \
  --name default --private-dns-zone privatelink.database.windows.net --zone-name sql

# A second server in the paired Region and a failover group, so the whole database can move together
az sql server create --resource-group $RG --name $PARTNER --location $PARTNER_LOCATION \
  --enable-ad-only-auth --external-admin-principal-type Group \
  --external-admin-name orders-db-admins --external-admin-sid $ADMIN_ID \
  --enable-public-network false --minimal-tls-version 1.2
az sql failover-group create --resource-group $RG --name orders-fog \
  --server $SERVER --partner-server $PARTNER --add-db orders \
  --failover-policy Automatic --grace-period 1

# Practise the restore: a new database from the backups, at a time you choose (UTC)
az sql db restore --resource-group $RG --server $SERVER --name orders --dest-name orders-restore-test \
  --time "2026-10-29T08:30:00Z"

# Assumes azurerm provider 4.x. The private endpoint is for the primary server; add a second server and
# azurerm_mssql_failover_group in the paired Region for cross-Region failover.
provider "azurerm" {
  features {}
}

variable "admin_object_id" { type = string }   # Entra group that administers the server

data "azurerm_client_config" "current" {}

resource "azurerm_resource_group" "orders" {
  name     = "rg-orders-sql"
  location = "centralindia"
}

resource "azurerm_mssql_server" "orders" {
  name                          = "orders-sql-001"
  resource_group_name           = azurerm_resource_group.orders.name
  location                      = azurerm_resource_group.orders.location
  version                       = "12.0"
  minimum_tls_version           = "1.2"
  public_network_access_enabled = false

  azuread_administrator {
    login_username              = "orders-db-admins"
    object_id                   = var.admin_object_id
    tenant_id                   = data.azurerm_client_config.current.tenant_id
    azuread_authentication_only = true
  }
}

resource "azurerm_mssql_database" "orders" {
  name        = "orders"
  server_id   = azurerm_mssql_server.orders.id
  sku_name    = "GP_S_Gen5_2"   # General Purpose, serverless, 2 vCores maximum
  max_size_gb = 32

  min_capacity                = 0.5
  auto_pause_delay_in_minutes = 60
  storage_account_type        = "Zone"

  short_term_retention_policy {
    retention_days = 14
  }

  long_term_retention_policy {
    weekly_retention  = "P4W"
    monthly_retention = "P12M"
    week_of_year      = 1
  }

  tags = { owner = "orders-team" }
}

resource "azurerm_virtual_network" "orders" {
  name                = "vnet-orders"
  location            = azurerm_resource_group.orders.location
  resource_group_name = azurerm_resource_group.orders.name
  address_space       = ["10.30.0.0/16"]
}

resource "azurerm_subnet" "data" {
  name                 = "snet-data"
  resource_group_name  = azurerm_resource_group.orders.name
  virtual_network_name = azurerm_virtual_network.orders.name
  address_prefixes     = ["10.30.1.0/24"]
}

resource "azurerm_private_dns_zone" "sql" {
  name                = "privatelink.database.windows.net"
  resource_group_name = azurerm_resource_group.orders.name
}

resource "azurerm_private_dns_zone_virtual_network_link" "sql" {
  name                  = "orders-sql-link"
  resource_group_name   = azurerm_resource_group.orders.name
  private_dns_zone_name = azurerm_private_dns_zone.sql.name
  virtual_network_id    = azurerm_virtual_network.orders.id
}

resource "azurerm_private_endpoint" "sql" {
  name                = "pe-orders-sql"
  location            = azurerm_resource_group.orders.location
  resource_group_name = azurerm_resource_group.orders.name
  subnet_id           = azurerm_subnet.data.id

  private_service_connection {
    name                           = "orders-sql"
    private_connection_resource_id = azurerm_mssql_server.orders.id
    subresource_names              = ["sqlServer"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "default"
    private_dns_zone_ids = [azurerm_private_dns_zone.sql.id]
  }
}

# pip install pyodbc azure-identity    (and install "ODBC Driver 18 for SQL Server" from Microsoft)
# One-off, as the Entra admin:  CREATE USER [orders-app] FROM EXTERNAL PROVIDER;
#                               ALTER ROLE db_datareader ADD MEMBER [orders-app]; ALTER ROLE db_datawriter ADD MEMBER [orders-app];
import struct
import time

import pyodbc
from azure.identity import DefaultAzureCredential

SERVER = "orders-sql-001.database.windows.net"   # with a private endpoint this name resolves to a private address
DATABASE = "orders"
SQL_COPT_SS_ACCESS_TOKEN = 1256                   # the ODBC attribute that carries an Entra access token
TRANSIENT = {"40613", "40197", "40501", "49918", "49919", "49920"}

credential = DefaultAzureCredential()


def connect():
    """Open an encrypted connection. The Entra token replaces a password, and the driver sends it in a struct."""
    token = credential.get_token("https://database.windows.net/.default").token.encode("utf-16-le")
    packed = struct.pack(f"<I{len(token)}s", len(token), token)
    return pyodbc.connect(
        f"Driver={{ODBC Driver 18 for SQL Server}};Server=tcp:{SERVER},1433;Database={DATABASE};"
        "Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30",
        attrs_before={SQL_COPT_SS_ACCESS_TOKEN: packed})


def place_order(conn, customer_id, total_cents):
    """Insert one order in a transaction and return its id (OUTPUT hands the new key back)."""
    cursor = conn.cursor()
    try:
        cursor.execute(
            "INSERT INTO dbo.orders (customer_id, total_cents) OUTPUT INSERTED.id VALUES (?, ?)",
            customer_id, total_cents)
        order_id = cursor.fetchone()[0]
        conn.commit()
        return order_id
    except Exception:
        conn.rollback()
        raise
    finally:
        cursor.close()


def is_transient(error):
    return any(code in str(error) for code in TRANSIENT)


def with_retry(action, attempts=5):
    """A serverless database that is resuming, or a failover, answers with a transient error. Back off and try again."""
    delay = 2
    for attempt in range(attempts):
        conn = None
        try:
            conn = connect()
            return action(conn)
        except pyodbc.Error as error:
            if attempt == attempts - 1 or not is_transient(error):
                raise
            time.sleep(delay)
            delay *= 2
        finally:
            if conn is not None:
                conn.close()


if __name__ == "__main__":
    print("New order:", with_retry(lambda c: place_order(c, 42, 129900)))

// Program.cs: sign in with Microsoft Entra, retry transient errors, and insert an order
// NuGet package: Microsoft.Data.SqlClient
using Microsoft.Data.SqlClient;

var builder = new SqlConnectionStringBuilder
{
    DataSource = "tcp:orders-sql-001.database.windows.net,1433",
    InitialCatalog = "orders",
    Authentication = SqlAuthenticationMethod.ActiveDirectoryDefault,   // managed identity, developer sign-in or environment credentials
    Encrypt = SqlConnectionEncryptOption.Mandatory,
    ConnectTimeout = 30
};

// Built-in retry logic: a serverless database that is resuming, or a failover, produces transient errors
var retry = SqlConfigurableRetryFactory.CreateExponentialRetryProvider(new SqlRetryLogicOption
{
    NumberOfTries = 5,
    DeltaTime = TimeSpan.FromSeconds(2),
    MaxTimeInterval = TimeSpan.FromSeconds(30),
    TransientErrors = new[] { 40613, 40197, 40501, 49918, 49919, 49920 }
});

await using var conn = new SqlConnection(builder.ConnectionString) { RetryLogicProvider = retry };
await conn.OpenAsync();

await using var tx = (SqlTransaction)await conn.BeginTransactionAsync();
await using var cmd = new SqlCommand(
    "INSERT INTO dbo.orders (customer_id, total_cents) OUTPUT INSERTED.id VALUES (@customer, @total)", conn, tx);
cmd.Parameters.AddWithValue("@customer", 42L);
cmd.Parameters.AddWithValue("@total", 129900);

var id = (long)(await cmd.ExecuteScalarAsync())!;
await tx.CommitAsync();
Console.WriteLine($"Created order {id}");

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

For applications that depend on server-level SQL Server features, Azure SQL Managed Instance or SQL Server on a virtual machine is the closer fit than SQL Database. The open-source engines have their own services: Azure Database for PostgreSQL and Azure Database for MySQL. Applications that use the database often run on Azure Functions or Azure Virtual Machines.