Retention and legal hold

Retention is the only maintenance task here that changes answers, and the only one with a deadline set by a party who does not negotiate (a regulator or a court).

Immutable storage, time travel, and "remove this person's data within 30 days" are in direct contradiction. There are two resolutions:

1. Rewrite every file that contains the person's rows and expire every snapshot that references them. This forcibly caps your time-travel depth at the regulatory window.
2. Crypto-shredding. Encrypt each person's data with that person's own key. To "delete" the data, destroy the key. Deleting a key is O(1) (constant time), instead of a rewrite. But it requires per-subject key granularity to have been chosen years earlier. This is early binding (a decision fixed at design time) with no retrofit path.

Notice the shape of the cost: deletion cost is proportional to the file that contains the row, not to the row. Deletion-heavy tables therefore want small files, and scan-heavy tables want large ones. That is a direct contradiction inside one table. Delete vectors defer the problem; compaction settles it.

Legal hold is the mirror image. An outside authority forbids a maintenance operation (for example, "do not delete anything about this case"). So GC and expiry need a per-object suppression path that every maintenance job consults before it deletes. This is an organizational constraint that appears as a code branch.