The first work nobody requested
Why does a correct table degrade on its own, and why does maintenance get switched off?
The first layer whose whole job is work nobody requested
Think about every operation in a storage system so far: a read, a write, a query, a commit. Each has a requester, a deadline and a correctness obligation. Someone is waiting, and the answer must be right.
Table maintenance is different. It is work that:
- nobody requested,
- produces no new information,
- and leaves the logical content of the table exactly as it was.
Compaction (merging many small files into fewer big ones) does not change a single answer. Neither does vacuum (deleting unused files), re-clustering (reordering data inside files), statistics refresh, or manifest rewriting. The table before and after is the same table.
So the constraint that disappears here is correctness of the result. You cannot get a wrong answer by compacting. That removes a large part of the design effort that other parts of a database need: isolation (concurrent users not disturbing each other), consistency and crash recovery. In its place appears something new: scheduling and economics with no deadline.
The new constraint is entropy under continuous write. Entropy here means "disorder." The physical layout of the table gets worse as data arrives, and it gets worse whether or not anything is wrong.
Three degradations, each from a different mismatch
- File sizes drift below the best size. Writers produce files at a rate of arrival rate × commit interval (how much data arrives, and how often they save it). Readers want files sized by the object store's cost arithmetic (a fixed delay per request, see Layout restoration). These are two unrelated quantities. There is no reason for them to agree.
- Sort order decays. New data is ordered by when it arrived. Queries filter by what the data is about (a city, a customer). Only a rewrite can reconcile the two.
- Metadata grows without bound. Immutability means every commit adds a new version and nothing is ever removed in place, so, like every immutable layer, the table grows an indirection layer and a collector.
None of these are faults. There is no bug to fix and no failure to recover from. This is the natural direction of an append-only storage layer under load, and maintenance is the continuous counter-force. That is why this mechanism is janitorial rather than surgical: a janitor's work is never finished, only currently caught up.
The bill is paid by a different party
Earlier designs in a storage system all offer the same bargain: accept a fast, local, unordered write now, and settle up later. Merge-on-read, tombstones, copy-on-write, log-structured layout (only appending, never overwriting), and optimistic manifest commits are all examples. Maintenance is "later."
The writer took the cheap path. Now either every reader pays for the mess at every query, or the maintenance budget pays once. So the governing question of this mechanism is not "how do I do this correctly?" but:
Core tension, in one line: maintenance is the interest payment on writes you made cheap, and it is the only work in the system that no one is waiting for.
Why maintenance gets switched off
The last part of that sentence is the whole political problem of the layer. Work with no requester has no advocate. It loses every contest for compute. It has no SLO (service level objective, a promised target such as "99% of queries under 5 s"). It is the first thing switched off under cost pressure. And its absence is invisible until the read-cost curve bends upward.
This is why every mature system eventually makes maintenance automatic and non-optional instead of scheduled and discretionary. The reason is not that automation is elegant. A scheduled maintenance job is a job that will eventually be skipped.
Deferred maintenance accrues interest, and the interest compounds. Rewriting N small files costs roughly N. But read slowdown is also roughly proportional to N, and you pay it continuously while you wait. The total cost is like the area under a rising line, which grows with the square of the delay time. Worked example: if the extra read cost grows by r each day, then after t days the extra cost paid so far is about r·t²/2. Waiting 10 days gives r × 100 / 2 = 50r. Waiting 20 days gives r × 400 / 2 = 200r. Doubling the delay quadruples the cost. This is why maintenance backlogs do not degrade gracefully.