A subject erasure request arrives for one customer. Their rows sit in a lakehouse table of 4 billion rows in 1,100 partitions, with 30 days of snapshot retention, plus a search index and two downstream marts. Roughly what does honouring it cost, and which assumption dominates?

The assumptions, stated

• One customer's rows are scattered across partitions rather than localised, because the table is partitioned by date and the customer transacted over three years.
• Files average 256 MB; a partition holds roughly 10 files.
• Deleting a row means rewriting every file that contains one, because the files are immutable.
• Snapshot retention of 30 days means old versions still hold the data until they expire.

The arithmetic

Files touched is the number that matters, not rows deleted. A customer with 1,000 events spread over 800 days touches roughly 800 partitions and, if their rows land in one file per partition, about 800 files. Rewriting 800 files of 256 MB is roughly 200 GB of read and 200 GB of write — for one person's data.

That is the single-request cost. The regime changes with request volume. At one request a week the rewrite is a background job nobody notices. At 500 a week, the naive approach rewrites the table continuously and never finishes.

Which assumption dominates

Whether erasure can be batched. One request costs 200 GB; a hundred requests batched into one rewrite pass cost barely more than one, because the same files are being rewritten either way. Batching converts a per-request cost into a per-cycle cost, and the design question is therefore not "how do we delete a row" but "what is the longest deletion cycle the regulator and our policy accept" — commonly 30 days against a typical one-month statutory response window, which leaves room for a weekly cycle.

The second dominant assumption is snapshot retention. Rewriting files does not erase anything while a 30-day snapshot still references the old ones. The data is genuinely gone only after expiry, which means the honest completion time is the rewrite plus the retention window, and any statement to a regulator that ignores this is wrong.

What the number rules in or out

It rules out row-level deletion on demand as a design. It rules in one of two patterns:

• Crypto-shredding: encrypt per-subject with a key held in a key store, and erase by destroying the key. Deletion becomes constant-time regardless of data volume. What it costs: every read now depends on the key service, key management becomes a correctness dependency, and analytical queries over encrypted columns lose their statistics and their pruning.
• Batched purge cycles with a tombstone registry, so requests accumulate and the table is rewritten on a schedule, with the registry proving what was requested and when.

When this is over-engineering

A dataset under a few hundred gigabytes with a handful of requests a year should just be rewritten. The mechanisms above exist for volume, and adopting crypto-shredding for a table that could be rewritten in twenty minutes adds a permanent operational dependency to avoid a cost nobody was paying.

The obligation is also not uniform. Derived aggregates that cannot identify an individual are usually outside the erasure scope, and the most effective move in most estates is not faster deletion but reducing the number of copies that hold identifiable data at all — which is a modelling decision taken years earlier.

Prefer batched purge cycles unless request volume genuinely forces crypto-shredding, and note the failure each carries: a batched cycle fails by overrunning its window silently, so alert on the age of the oldest outstanding request rather than on job success; crypto-shredding fails by losing a key that was still needed, which is unrecoverable data loss rather than a delay. European erasure obligations have been operative since 2018 and both designs are now well documented; the choice between them is a volume question, not a compliance one.