The previous three lessons compared structures by describing how they work. There is a better way to compare them, which is to measure the same three ratios for each and let the numbers settle the argument.

Why ratios rather than descriptions

A structural description tells you how something behaves in principle. A ratio tells you how much of a specific resource it consumes per unit of useful work, which is the quantity a capacity plan needs and the quantity a benchmark actually measures.

Making this shift is the point of the lesson. Arguments about whether one structure is better than another are unresolvable in the abstract and immediately resolvable once both are expressed as three numbers for a named workload, because then the question becomes which resource is scarce rather than which design is superior.

Read amplification defined

The number of physical reads performed to satisfy one logical read. A point lookup that consults four files has read amplification of four, and a scan that reads ten times the bytes it returns has read amplification of ten.

The definition needs care because it can be counted in operations or in bytes, and the two give very different answers for the same workload. A point lookup is best counted in operations, since each one costs a latency, while a scan is best counted in bytes, since it is bandwidth-bound. Mixing the two produces meaningless comparisons.

Write amplification defined

The number of bytes written to the device per byte the application wrote. A log-structured store rewriting data through five levels at a factor of ten has write amplification near fifty. A B-tree writing an eight-kilobyte page for a hundred-byte row has eighty.

The B-tree figure surprises people and it is the most useful number in this lesson, because it shows write amplification is not a log-structured problem. Both designs amplify writes substantially and they do it for different reasons, so comparing them requires computing both rather than assuming one.

Space amplification defined

The bytes occupied on the device per byte of live logical data. A B-tree at seventy percent page utilisation has space amplification around one and a half. A log-structured store with obsolete versions awaiting compaction can be anywhere from one and one tenth to two.

Including this third ratio matters because it is the one most often left out of comparisons, and it is the one that produces an outage rather than a slowdown when it is wrong. Space is a hard limit in a way that bandwidth is not.

Why the three cannot be minimised together

Any mechanism that reduces one consumes a resource that increases another. Compacting more reduces read and space amplification and increases write amplification. Keeping pages fuller reduces space amplification and increases split frequency, which increases write amplification.

This is the central fact of storage engine design and it holds across every structure rather than being a property of one. Recognising it converts the question from which design wins to which point on a surface a particular workload should occupy, and that question has an answer.

Why the product is roughly conserved

Across the plausible configurations of a given structure, improving one ratio worsens another by a comparable factor, so the product stays within a narrow band. Configuration moves cost between resources rather than removing it.

Understanding this prevents a great deal of wasted tuning. A configuration change that appears to improve everything is almost always measuring a workload that does not exercise the ratio it degraded, and the degradation will appear later under a different load. Genuine improvements come from changing the structure or the data, not the configuration.

What a hardware change does

New hardware changes which ratio is expensive rather than changing any of the ratios. Flash made random reads cheap, which devalued low read amplification. Persistent memory and fast flash narrow the gap between random and sequential writes, which devalues low write amplification.

This is why the field keeps reversing its conclusions without anybody having been wrong. The ratios of a structure are properties of the structure, and the weights applied to them are properties of the hardware, so a correct decision from one era becomes an incorrect one without any new information about the structures themselves.

Why write amplification has a cost beyond bandwidth

Flash devices wear out in proportion to bytes written, so write amplification consumes a finite endurance budget. A device rated for a certain number of full writes per day delivers a fraction of that to the application.

Treating endurance as a resource alongside bandwidth is unfamiliar and necessary. A design with write amplification of fifty on a device rated for three full drive writes per day gives the application the equivalent of six hundredths, which can be the binding constraint on the deployment and is invisible in any latency measurement.

Why space amplification is the one that causes outages

Running out of bandwidth makes a system slow. Running out of space makes it stop, often in a way that also prevents the cleanup that would recover the space, since compaction and rebuilding both need temporary room.

The asymmetry justifies treating space differently from the other two. A plan should provision space for the worst case rather than the average, and should verify that the worst case leaves room for the operation that recovers from it, which is a check almost nobody performs until the first time it matters.

Why the ratios are better than a benchmark number

A benchmark reports throughput for one configuration under one load on one machine, which answers a question nobody asked twice. The three ratios are properties of a structure under a named workload, so they transfer.

Transferability is the reason to prefer them. A throughput figure tells you what happened on somebody else's hardware with somebody else's data, while a set of ratios lets you compute what will happen on yours, because the ratios multiply against your write rate and your live data size to give bandwidth and space directly.

Why all three must be quoted together

A claim about one ratio in isolation is not evidence of anything, because improving it at the expense of another is always available. Any figure quoted alone has probably been obtained that way.

Insisting on all three is the cheapest defence against a misleading comparison. A store reporting excellent read amplification may be compacting constantly, and one reporting excellent write amplification may be accumulating files and obsolete versions, and in both cases the number offered is true and the omission is what matters.

Why the vocabulary is worth adopting even informally

Two engineers disagreeing about a storage decision will converge within minutes once each states which ratio they are protecting, because the disagreement is almost always about which resource is scarce rather than about any fact.

That convergence is most of the value. The terms are precise enough to end an argument and simple enough that nobody needs to look them up, which is a rare combination in a field where most disagreements are about definitions rather than about systems.

What to take from the three ratios

Three things. Expressing a structure as three measured ratios for a named workload turns an unresolvable argument about designs into an answerable question about which resource is scarce. The three cannot be minimised together and their product is roughly conserved across configurations, so tuning moves cost between resources rather than removing it, and real gains come from changing the structure or the data. And hardware changes the weights rather than the ratios, which is why the field's conclusions reverse periodically without anybody having been wrong.