deleteRange

Deletes every key in [from, to], both bounds inclusive, and returns how many.

val retired = store.deleteRange(Key.of("event:2026-07-01"), Key.of("event:2026-07-31"))
store.compact()   // tombstones are reclaimed by compaction, not by this call

This is the loop a caller would otherwise write, written once by the party that knows the rules. Retention by key range is the whole of what a staging buffer and an archive need, and getting it right by hand means knowing four things that are not on any signature: that the scan must be scoped by a Snapshot or a concurrent compaction can change what it sees, that the deletes belong in a WriteBatch rather than being issued one at a time, that a tombstone is reclaimed by compaction and not by the delete, and that a tombstone may only be dropped at the bottom-most level below the oldest live snapshot. Three of those four are invariants a caller should never have had to learn.

Deliberately the cheap shape, and it is worth knowing that it is a choice. This emits point deletes in bounded batches — no new operation id, no format change, no change to compaction, no new invariant. A real LSM range tombstone is the other design and the format has room for it, but it would change what a merge emits, what EntryCursor collapses and, most seriously, the tombstone-drop rule, which is on the short list of invariants that fail by returning a deleted document to a reader. That is not a change to make without a measurement saying this version is not enough.

So the cost is proportional to the number of keys deleted, not to the size of the range, and it writes one tombstone per key. A caller retiring a very large range should expect the write amplification of exactly that.

Atomic per batch, not overall. A failure part-way leaves the batches that were committed committed — this is a retention loop, not a transaction, and the alternative would be one commit holding every tombstone, which for a large range is a record the log cannot hold. The count returned is what was actually deleted.

The snapshot is taken here, so keys written during the call are not deleted: the range is emptied as of the moment it was asked for, which is what makes a repeated call converge rather than race a writer.

Parameters