Provisioned vs Serverless Capacity
Paying for a fixed database size continuously, versus paying for capacity consumed with automatic scaling — a crossover decision driven by duty cycle.
Provisioned buys a fixed instance size, billed by the hour whether used or not. Predictable performance, predictable cost, and it wastes money on anything with a low duty cycle.
Serverless scales capacity automatically with load and bills per unit consumed. It removes capacity planning, scales to near-zero for idle workloads, and costs substantially more per unit at sustained utilisation.
The crossover is the whole decision and it is arithmetic, not principle. Serverless wins for development environments, internal tools, spiky workloads and anything genuinely idle much of the time. Provisioned wins above roughly 50–70% sustained utilisation, where the per-unit premium exceeds the savings from scaling down.
Two things to check before choosing serverless. Scaling latency: capacity increases take seconds to tens of seconds, so a sharp spike is served at the old capacity while it catches up — which for a doorbuster or a cron-triggered burst is exactly the wrong behaviour. And cold-start or resume behaviour for tiers that scale to zero: the first request after idle can wait seconds, which is fine for a dev database and not for a customer-facing one.
The common right answer is mixed: serverless for non-production and spiky workloads, provisioned with committed-use discounts for the steady production baseline.