Serverless vs Provisioned Databases: How to Choose

A serverless database still runs on servers. “Serverless” describes the capacity and operating model presented to you: the service adjusts capacity within configured limits and charges according to that model instead of requiring you to choose one fixed instance size. Updated October 9, 2026. The decision is not modern versus old. It is variable capacity versus predictable provisioned capacity.

​

How the models differ

A provisioned relational database runs on a selected instance class or cluster shape. You pay for that capacity while it is running. Scaling usually means modifying the instance or adding replicas. A serverless relational database exposes capacity units and scaling boundaries. The platform adjusts compute as demand changes. Depending on the engine and configuration, it may reduce to a low minimum or pause when idle, then add capacity as activity returns. Storage, backups, I/O, data transfer, replicas, and monitoring can still produce separate charges in both models.

​

Workload shape matters

Serverless capacity often fits:

• Development and test databases with long idle periods
• Spiky workloads with unpredictable peaks
• New products without a stable baseline
• Seasonal or event-driven applications
• Tenant or workflow systems where activity arrives in bursts

Provisioned capacity often fits:

• Steady 24-hour production traffic
• Latency-sensitive systems that cannot tolerate scaling transitions
• Workloads with a stable, well-understood baseline
• Databases that need a specific memory-to-CPU ratio
• Systems where reserved pricing materially improves the steady rate

A serverless database can cost more than a well-sized provisioned instance when it remains near its maximum capacity all day. A provisioned database can waste money when it is idle most of the week.

​

Scaling is not instantaneous or unlimited

Set minimum capacity high enough to hold the active working set and serve normal traffic. Set maximum capacity high enough for a real peak but low enough to protect the budget and downstream systems. Database scaling cannot fix slow queries, missing indexes, excessive connections, or lock contention. More capacity may temporarily hide those problems while making them more expensive.

​

Connections need separate planning

Applications often open connections faster than a database can scale. Serverless application compute can make this worse because hundreds of short-lived functions or tasks may create connection storms. Use bounded connection pools. Consider a managed database proxy when it matches the engine and failure model. Monitor active connections, wait time, transaction duration, and failed connection attempts. A proxy adds another component and cost. It does not make unbounded application behavior safe.

​

Availability and recovery are independent choices

Serverless capacity does not automatically mean multi-region or zero downtime. Review the database’s Availability Zone design, failover behavior, backup retention, point-in-time recovery, replica topology, and maintenance process. Ask the same recovery questions for either model:

• What is the recovery time objective?
• What is the recovery point objective?
• Has restore been tested?
• Which application changes are compatible during failover?
• How are credentials and encryption keys recovered?

​

Compare the full cost

Include:

• Minimum and average compute capacity
• Peak duration
• Storage and I/O
• Backup retention
• Data transfer
• Replicas and cross-region copies
• Performance monitoring
• Proxy capacity
• Engineering time spent scaling and recovering

Run the comparison with observed usage, not only list-price examples.

​

A practical decision

Choose serverless when variable demand and reduced capacity management are worth the scaling and pricing model. Choose provisioned when the baseline is stable and predictable performance or committed pricing wins. Revisit the choice as the product changes. A new workload may start serverless, establish a stable baseline, and later move to provisioned capacity. Another workload may become bursty after background jobs or previews are introduced and move in the opposite direction. Springwinter lets you create managed PostgreSQL or MySQL resources in your AWS account and view capacity and cost beside the project. See databases and cost. The engine still needs deliberate limits, monitoring, backups, and query design regardless of the capacity label.

​

Frequently asked questions

​

Sources and further reading

• Amazon Aurora Serverless v2
• Amazon RDS instance classes
• Amazon RDS Proxy