Designing Around Azure SQL Database Serverless: An Architecture Note for Variable Workloads

The decision problem

You have a database-backed workload that is busy some hours and nearly idle the rest — an internal reporting tool, a dev/test environment, a line-of-business app used only during business hours. Paying for provisioned vCores around the clock wastes money, but a bad serverless configuration can trade that savings for 10–30 second cold-start stalls and throttled bursts. This note lays out the smallest design that captures the cost benefit without inheriting the latency traps, along with the checks and failure modes that should shape your final settings.

Requirements to confirm before choosing serverless

Serverless is only the right answer if all of these hold:

• Idle windows exist. If the database receives queries every minute around the clock, auto-pause never fires and you pay per-second compute anyway.
• Cold-start latency is tolerable. Resuming from a paused state typically takes on the order of tens of seconds. A user-facing checkout flow cannot absorb that; a nightly report can.
• Bursts are bounded. Scaling up to max vCores is not instant — it can take up to roughly 30 seconds. Sustained high-volume bursts may be throttled during ramp-up.
• No always-on features conflict. Certain features (for example, long-running transactions, open sessions in some configurations, or features like sync groups) can prevent auto-pause from engaging. Verify your feature set against the current documentation.

The smallest suitable design

Start with the minimum that meets requirements, and only add settings when a measured need appears:

• Min vCores: set to the floor your steady-state load needs while active — often 0.5–1 vCore. Note the research assumption of a 1-vCore enforced minimum in some configurations; confirm the current floor for your region and service tier, as this has changed over time.
• Max vCores: set to absorb your measured peak concurrency, not a guess. Pull the peak from an existing workload's CPU metrics if you have one.
• Auto-pause delay: 1 hour is a sane default. A 5-minute delay maximizes savings but means frequent cold starts; a 1-day delay barely saves anything. The delay is configurable from 1 minute to 1 day.

Everything else — private endpoints, customer-managed keys, extended retention — is a trust-boundary decision, not a sizing one, and is covered next.

Trust and data boundaries

The serverless tier changes compute billing, not the security model. The boundaries to draw explicitly:

• Network: disable public network access and attach a private endpoint so only approved VNet subnets can reach the database. VNet service endpoints are the lighter alternative but keep the public endpoint reachable. A misconfigured private endpoint or DNS zone blocks all connections — treat connectivity as a monitored dependency, not a one-time setup task.
• Encryption at rest: Transparent Data Encryption (TDE) is on by default with a service-managed key. Move to a customer-managed key in Azure Key Vault only if compliance requires key custody; it adds a hard dependency — if the key becomes unavailable, the database becomes unavailable.
• Auditing: stream audit logs to Azure Monitor or a storage account if you have retention or compliance obligations. Auto-pause does not exempt you from audit coverage.
• Recovery: automatic backups with point-in-time restore are included (retention up to 35 days depending on configuration). Confirm the retention period matches your recovery point objective; serverless does not change backup behavior, but a paused database still has restore obligations.

Operational checks

Instrument before you trust the design:

• Azure Monitor metrics: track CPU percentage, vCore scaling events, and auto-pause/resume events. Alert on unexpected scale-to-max events (a runaway query) and on resume latency exceeding your tolerance.
• Controlled pause-resume test: in a staging database, force a pause by waiting out the delay, then time the first query after resume. Measure this against your latency budget rather than trusting published figures.
• Cost validation: after two weeks, compare actual vCore-seconds billed against what the equivalent provisioned tier would have cost. Pricing changes; verify current per-vCore-second rates on the Azure pricing page before committing to projections.
• Connectivity check: run a simple query from each approved subnet after any network change. A private endpoint DNS regression otherwise surfaces as a production outage.

Failure modes to plan for

• Cold-start stall: first request after pause waits for resume. Mitigation: a keep-alive ping defeats the cost savings, so instead move latency-sensitive paths to a provisioned tier or accept and document the stall.
• Burst throttling: a sudden load spike outruns the scale-up ramp. Mitigation: raise max vCores if peaks are real, or queue work to smooth the burst.
• Pause never engages: a background job, open connection, or conflicting feature keeps the database "active," silently erasing savings. Mitigation: alert on zero auto-pause events over a rolling window.
• Network isolation outage: private endpoint or DNS misconfiguration blocks all traffic. Mitigation: the connectivity check above, plus an alert on connection failures.

Conditions that should change the design

Revisit the choice when any of these become true: idle windows disappear (move to provisioned — it becomes cheaper and simpler); resume latency starts violating an SLA; sustained load keeps the database pinned at max vCores (serverless at max often costs more than equivalent provisioned capacity); or you need a feature incompatible with auto-pause. Serverless is a billing model, not a commitment — the metrics you set up above are exactly what tells you when to leave it.