Serverless database vs provisioned cost: pay per use or reserve capacity?
Serverless databases scale capacity automatically and bill per use, costing nothing when idle; provisioned databases reserve fixed capacity at a flat rate. The crossover is utilization, and it decides which is cheaper. Here is the math with numbers.
Quick answer
Serverless databases (like Aurora Serverless v2, Cosmos DB serverless, or DynamoDB on-demand) scale capacity automatically and bill for what you use, so they cost near zero when idle and scale with load, but their per-unit rate is higher than provisioned. Provisioned databases reserve a fixed capacity at a flat rate, cheaper per unit but paid whether busy or idle. The crossover is utilization: below a threshold, serverless is cheaper because it does not pay for idle; above it, provisioned is cheaper. So use serverless for spiky, intermittent, or unpredictable database load and provisioned for steady, high-utilization databases.
Databases now come in serverless and provisioned flavors, and the choice is a cost decision as much as an operational one. Serverless scales capacity up and down automatically and bills for consumption, so an idle database costs almost nothing. Provisioned reserves a fixed amount of capacity at a flat rate, cheaper per unit but paid around the clock. Which is cheaper depends entirely on how steadily the database is used.
Two capacity models
| Factor | Serverless database | Provisioned database |
|---|---|---|
| Idle cost | Near zero (scales down) | Full reserved rate |
| Per-unit rate | Higher | Lower |
| Scaling | Automatic to demand | Fixed until you resize |
| Best for | Spiky, intermittent | Steady, high-utilization |
Aurora Serverless v2 bills per ACU-hour of capacity actually used, scaling with load, while a provisioned Aurora instance bills a flat hourly rate for its full size regardless of traffic. A database that is busy a few hours a day and idle the rest pays only for those busy hours on serverless, while provisioned pays 24/7, so serverless wins on intermittent load, as the Aurora Serverless v2 guide covers.
Why utilization decides it
Serverless charges a premium per unit in exchange for not paying when idle, so it is cheapest exactly when utilization is low or spiky. As a database runs busy for more of the day, the idle savings shrink and the serverless per-unit premium starts to dominate, until a steadily-utilized provisioned instance at its lower rate becomes cheaper. The crossover is roughly where the serverless premium times your busy hours exceeds the provisioned flat rate, the same logic as DynamoDB on-demand versus provisioned.
Where each wins
Serverless wins for dev and test databases idle overnight, spiky workloads, new applications with unknown load, and anything that scales to near zero regularly. Provisioned wins for production databases under steady, predictable load that keeps capacity busy most of the time, where the lower per-unit rate over 24 hours beats the serverless premium. Reserved or committed pricing on provisioned widens its advantage for steady load, per the reserved capacity guide.
Finding your crossover
Estimate your database utilization pattern over a day and week. If it is spiky or often idle, serverless is cheaper and simpler; if it runs busy most of the time, provisioned at its lower rate wins. Many teams run dev and variable workloads serverless and steady production provisioned. Right-size the provisioned option so its flat rate is not padded with unused capacity. Price both the serverless and provisioned configurations against the resource catalog so the crossover is a concrete number before you choose.
FAQ
Is a serverless or provisioned database cheaper?
It depends on utilization. Serverless databases bill for what you use and scale to near zero when idle, so they are cheaper for spiky, intermittent, or unpredictable load. Provisioned databases reserve fixed capacity at a lower per-unit rate paid around the clock, so they are cheaper for steady, high-utilization load. The crossover is where the serverless per-unit premium over busy hours exceeds the provisioned flat rate.
When is a serverless database cheaper?
When the database is idle or spiky: dev and test databases idle overnight, workloads busy only a few hours a day, new applications with unknown load, and anything that regularly scales to near zero. Serverless pays only for capacity actually used, so it avoids the 24/7 cost a provisioned instance pays whether busy or idle, making it cheaper below the utilization crossover.
When is a provisioned database cheaper?
For production databases under steady, predictable load that keeps capacity busy most of the time. Provisioned reserves capacity at a lower per-unit rate, so over 24 hours of high utilization it beats the serverless per-unit premium. Reserved or committed pricing on provisioned widens this advantage further for steady load, making it the clear choice above the utilization crossover.
How do I find the serverless-versus-provisioned crossover?
Estimate your database utilization over a day and week, then compare the serverless cost, per-unit rate times capacity used during busy periods, against the provisioned flat rate for the equivalent size run 24/7. The crossover is roughly where the serverless premium times your busy hours exceeds the provisioned flat rate. Spiky or idle patterns favor serverless; steady busy patterns favor provisioned.
How does C3X help compare database capacity models?
C3X prices both the serverless and provisioned database configurations from Terraform before you deploy, so each option's cost is a concrete number. Combined with your expected utilization pattern, that makes the crossover explicit in the pull request, letting you choose serverless for spiky or idle databases and provisioned for steady ones at design time rather than discovering the trade-off on the bill.
What to do next
Find your database capacity crossover before you choose. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.