Vertical scaling is a step-function bill

Ask a cloud vendor for a slightly bigger database and you will find there is no such thing. A managed database is bought in tiers: a fixed ladder of sizes, each with its own amount of processing power, memory and connections, and each with its own price. When your current size runs out, the next size up is the next rung, and the next rung usually costs about twice as much.

That shape, a staircase rather than a slope, is the single most important thing to understand about database spending. It explains why the database line jumps rather than creeps, and why "just scale up" turns out to be such an expensive reflex.

The staircase and the curve

Draw your application's demand over a month as a line. It rises during the working day, falls overnight, spikes on a handful of busy days, and sits far below its peak for most of the hours in between. Now draw the database tier you are paying for as a flat line above it. The gap between the two lines is what you pay for and do not use.

With a staircase, that gap is never small. You cannot buy the tier that fits your average day, because the busy days would fall over. So you buy the tier that fits the busiest hour of the busiest day, and you pay for it every hour of the month.

One non-profit we spoke with had exactly one upgrade option on its database, and it doubled the monthly cost. There was no rung in between.

Headroom you use a few hours a month

Consider what the extra rung actually buys. If the previous tier coped with everything except a peak on a few afternoons, the new tier's additional capacity is in use for those afternoons and idle the rest of the time. Over a month of roughly 720 hours, headroom that matters for perhaps ten of them is being paid for in all 720.

Vendors are not hiding this; it is simply how a fixed-size engine has to be sold. A database cannot be grown one slice at a time the way application servers can; it is one machine, either the bigger one or the smaller one.

• Application servers scale in units, so the cost tracks demand fairly closely.
• The database scales in doublings, so the cost tracks the peak, not the demand.
• The peak is made mostly of reads, which is the part of the load that does not have to hit the database at all.

Why "just scale up" is a habit, not a decision

Scaling up is the easiest button in cloud operations. It is one setting, it takes effect quickly, and it makes the alarms stop. When the database is hot at three in the afternoon and customers are complaining, nobody convenes a cost review; someone clicks the next tier.

The trouble is that the click is permanent in practice. Scaling down is a change nobody wants to own, because if it goes wrong it goes wrong in public. So every upgrade becomes the new floor, and the floor only ever rises. A company that has scaled up four times over three years is paying roughly sixteen times its original database cost, for a workload that has almost certainly not grown sixteen-fold.

The other route, horizontal scaling (spreading the load across copies of the database and a distributed cache), is a large engineering project with long development and testing cycles. Most teams look at it, estimate the quarters involved, and click the tier button instead.

A step-function bill punishes small growth with large jumps, and rewards nobody for scaling back down.

Serving reads from memory changes the shape

The way to stay on a smaller rung for longer is to take load off the database that never needed to be there. For a typical application the large majority of that load is reads: lookups, permission checks, profile loads, list pages. If those are served from a memory cache that is kept in step with the database, the database itself only has to handle writes and act as the fallback if the cache is unreachable.

That does two things to the staircase. First, the database drops one or more rungs, because the peak it must be sized for is now a peak of writes, which is far smaller. Second, growth in users no longer pushes it toward the next rung, because new users mostly add reads, and reads are absorbed in memory. We have handled peak shopping days with the database at 99 percent of its processing and memory capacity and kept serving.

The cache has a cost of its own, but memory for the rows in active use is a much smaller line than a database engine sized to answer everything from disk, and it scales in small units rather than doublings.

What to check on your own bill

Look at your database tier history for the last two years. Count the upgrades. For each one, ask what hour of what day forced it, and whether that hour was made of reads or writes. If the answer is reads, that rung was bought to serve traffic a cache could have carried.

redfly is built to make that move without a rewrite: a memory cache in front of the database, kept in sync by redfly, with writes going straight through and reads falling back to the database automatically if the cache is ever unavailable.