Scaling Cloud Databases
Why database scaling is a different problem from scaling stateless services, and what actually works.
Executive summary Scaling a stateless service is easy: add more copies. Scaling a database is not, because the data has to move, stay consistent, and remain available while it does. The cloud offers two answers, provisioned capacity you resize and serverless capacity that resizes itself, and each fails in a different way. This paper maps how both scale, where the sharp edges are, and how to plan so a growth event is routine rather than an incident.
Why database scaling is a different problem
Most scaling advice is written for stateless compute, where the unit of scale is a disposable copy and the load balancer does the rest. Databases break that model. There is state to keep consistent, connections to manage, and a working set that has to fit in memory to stay fast. You cannot make a database faster simply by placing more instances behind it, because they all have to agree on the data.
That is why database scaling is the part of an architecture most likely to surprise a team. The application scaled smoothly for two years, and then a launch, a migration, or a seasonal peak arrived and the database became the wall everything hit at once.
The two scaling models
Serverful: you own the capacity curve
A provisioned database scales in two directions, and you drive both.
- Vertical scaling means moving to a larger instance: more CPU, memory, and I/O. It is the simplest lever and often the first one teams reach for. The cost is that a resize typically involves a failover or a maintenance window, and there is a ceiling: eventually the largest instance is not large enough.
- Horizontal scaling means adding read replicas to spread read traffic, or sharding to spread writes. Replicas are well understood and widely supported. Sharding is powerful and expensive in engineering time, because the application has to become shard-aware and cross-shard queries get harder.
The defining property of serverful scaling is that it is deliberate. You decide when to grow, you plan the change, and you carry the risk of getting the size wrong in either direction: too small and you throttle under load, too large and you pay for headroom every hour.
Serverless: the platform owns the curve
A serverless database scales capacity automatically in response to demand. On Amazon Aurora Serverless it is measured in capacity units that rise and fall by the second. On Azure SQL Database's serverless tier it auto-scales between a minimum and maximum vCore range and can pause during inactivity. Google's AlloyDB Serverless and Cloud Spanner scale without you choosing instances at all, and Spanner does it across regions by design.
The defining property is that scaling is continuous and automatic. You do not plan a resize; capacity follows the workload. The trade is that you give up some control and, as covered below, you accept a different failure mode.
The distinction that matters Serverful scaling fails by being wrong: the instance you picked is too small when the spike comes, or too large the rest of the time. Serverless scaling fails by being late: capacity is catching up to a burst it did not see coming. You are choosing which of those risks you would rather manage.
Where each model breaks
Knowing the failure modes in advance is most of the value of this comparison.
| Scenario | Serverful risk | Serverless risk |
|---|---|---|
| Sudden traffic spike | Fixed instance saturates; you scramble to resize | Capacity ramps, but not instantly; a short lag under a steep burst |
| Steady high load | Works well if sized right; wasted spend if oversized | Can cost more than a right-sized instance |
| Long idle periods | Paying full price for an idle instance | Scales to minimum or pauses; near-zero idle cost |
| Write-heavy growth | Sharding becomes an engineering project | Write scaling still bounded by the engine's model |
| Global distribution | Cross-region replicas to manage yourself | Available by design in some engines (for example Spanner) |
How to plan capacity so growth is boring
The goal is not to pick the model that never fails. It is to pick the model whose failure mode you can absorb, and then remove the surprises around it.
- Design for the spike you can name. Most teams know their peaks: a launch, a sale, month-end, a batch window. Size or configure for the named peak, not the average, and confirm the ceiling is above it.
- Separate reads from writes early. Read replicas and read-only endpoints are the cheapest scaling you will ever buy. Route reporting, search, and analytics off the primary before they compete with production writes.
- Set explicit floors and ceilings on serverless. Auto-scaling is not a blank check. A minimum capacity protects latency on the first request after idle; a maximum protects the bill from a runaway query or a retry storm.
- Rehearse the resize. For provisioned systems, know how long a scale-up takes and whether it fails over. A resize you have never practiced is a resize you will perform for the first time during an incident.
- Watch the working set, not just CPU. The moment the hot data no longer fits in memory, latency degrades sharply regardless of instance size. Track cache hit ratios as a leading indicator, not CPU alone.
Making the choice
Match the model to the shape of the load.
- Choose serverful scaling when the workload is steady and predictable, when you need a guaranteed performance floor, or when you require fine control over exactly how and when capacity changes.
- Choose serverless scaling when the load is spiky, seasonal, or often idle, when you want to avoid capacity planning, or when the cost of paying for constant headroom is hard to justify.
- Run both when different systems have different shapes, which is the common case: predictable core systems on provisioned capacity, variable and lower-stakes systems on serverless.
The takeaway A scaling event should never be the first time you learn how your database scales. Decide which failure mode you can live with, set explicit limits around it, and rehearse the one manual step you might have to take. Do that and elasticity keeps its promise.
Simcha Solutions designs and operates cloud data platforms where growth is a planned event rather than an emergency. The teams that scale calmly are the ones that chose their failure mode on purpose.