Managed Databases
Intermediate 12 min read Managed Databases

Serverless SQL and Aurora

SQL engines that scale with demand

Serverless relational (Aurora Serverless, Azure SQL serverless, Cloud SQL serverless editions) scales capacity up/down and pauses when idle. It brings classic SQL engines into the pay-for-use model.

Aurora Serverlessserverless SQLauto-pausecapacity scalingElastic
Prerequisites: Relational Managed Databases
Before we start

What you will learn

  • Explain how serverless relational scales and pauses
  • Compare engine-specific serverless mechanics
  • Choose when serverless SQL beats a fixed-size instance
In 60 seconds

A database cluster that scales capacity in ACUs (Aurora), DTUs/vCore tiers (Azure serverless), or pauses entirely — billed on usage, waking on demand. Great for spiky, dev, and low-traffic workloads with forgiving latency.

Introduction

What is this?

Aurora Serverless v2: scales capacity in ACUs continuously (min/max), multi-AZ capable, per-second billing. Azure SQL Database serverless: auto-pause/resume with min/max vCores, billed for compute while running + storage always. Cloud SQL serverless-ish editions reduce-manage size moves; Cloud Spanner is globally scalable serverless. Reads stay performance-consistent within scaling headroom; cold-pause adds wake latency.

Motivation

Why do you need it?

  • Dev/test databases shouldn't pay fixed CPU 24/7.
  • Spiky apps (campaigns, bursts) want capacity without over-provisioning.
  • Per-second billing matches real utilization.
  • Aurora v2 auto-scales within a range so traffic spikes don't tip the box.
Think about it

Mental model

Imagine

A food truck kitchen that expands to a second counter during rush hour

Think of

Serverless relational scaling

Slow Tuesday, one cook (paused/low); Friday peak, the truck preps more servers (scale ACU) and even closes (pause) when the park is empty, paying only for the counters actually used.

Mechanics

How it works

  • Capacity units (ACUs/vCores) step in pre-defined increments; min/max bound the range.
  • Monitoring drives in-place scaling; warm pools smooth the step (no restart).
  • Auto-pause flushes state to storage and frees compute when idle beyond a threshold.
  • On traffic, the cluster resumes (seconds to ~1 min) before serving queries.
  • Billing: compute per unit-hour used + storage per GB-month + I/O wherever charged.

Serverless relational control loop.

Traffic
Monitor
Scale
Idle?
Pause/Resume
Hands-on

Examples

Set serverless capacity bounds

Set serverless capacity bounds
# Aurora Serverless v2: 0.5 ACU min, 4 ACU max, on-demand
aws rds create-db-cluster --engine aurora-postgresql \
  --db-cluster-identifier appless --serverless-v2-scaling-configuration   MinCapacity=0.5,MaxCapacity=4
# Azure SQL serverless: min 0.5 vCore, max 2 vCore, auto-pause 60min
az sql db update -g app-rg -s app-sql -n appdb \
  --compute-model Serverless --auto-pause-delay 60 \
  --min-capacity 0.5 --max-capacity 2

Bounds prevent bill shocks while keeping the tail scales reachable.

Real world

In production

  • A marketing dashboard DB runs Aurora v2, scaling between 1-4 ACUs around campaign launches.
  • Azure SQL serverless powers a dev instance that auto-pauses at night, cutting compute spend 80%.
  • A SaaS on-ramp uses serverless during product evaluation, migrating to a fixed tier for committed tenants.
Guidelines

Best practices

  • Set min capacity to cover the acceptable latency floor (pausing losses ambitions).
  • Keep auto-pause off for latency-sensitive or busily-pinged apps.
  • Watch storage: serverless still bills storage continuously even while paused.
  • Benchmark scale-up responsiveness before promising p95 latency.
Watch out

Common mistakes

  • Auto-pausing a production API DB → every user request eats a wake-up (5-60s).
  • Setting min ACU equal to max: you've built a fixed instance, minus the savings.
  • Ignoring storage + I/O charges while focusing only on compute savings.
  • Migrating a huge, hot, predictable DB to serverless just to 'modernize' — fixed tier wins.
Root cause analysis

Common issues

Error
Every request waits seconds during wake
Root cause

Auto-pause too aggressive for the traffic

Fix

Increase pause delay or min capacity; or disable auto-pause for the busy window.

Error
Bill higher than expected
Root cause

I/O + storage charges ignored in the estimate

Fix

Add I/O to the model; move archive data to cold tiers.

When things break

Debugging tips

  • Cold resume slow: watch the 'resume' log; raise min capacity for that window.
  • Mystery cost: serverless bills I/O too — review I/O patterns, not just ACU hours.
  • Scaling thrash: min/max too tight or polling load jitter in monitoring.
  • Version drift: Aurora serverless features lag static versions occasionally — pin the release.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

Aurora Serverless v2 pauses compute and also stops storing data while idle.

Go deeper

Official documentation

AWS — Aurora Serverless v2
docs
Azure — SQL serverless
docs
GCP — Cloud Spanner
docs