There is a Parquet file in your Lakehouse right now holding data you told someone you deleted.

Not because a job failed. Run the query and you get zero rows; every engine agrees the row is gone. List the object versions in the bucket underneath and the file is still there, intact, readable by anyone with object access and by any engine pinned to an older snapshot. Both systems are working exactly as designed. Iceberg promised your readers would not see that row, and it kept the promise the instant the delete committed. It never said anything about bytes. The regulation is entirely about bytes.

What makes this hard is that the gap has no owner. There is no exception to catch, no failed job to page anyone about, and no dashboard that turns red. Most teams alarm on whether the VACUUM job succeeded, which tells you the job ran. It does not tell you the data is gone, and the table metadata will cheerfully report every row as deleted while the objects sit in storage. If your erasure evidence comes from the table, you are auditing the wrong system. The only honest answer comes from the bucket, and almost nobody asks it.

So we asked it. Two of us built harnesses that drive real Apache Iceberg tables through erasure requests in virtual time, then merged them, and measured how long a deleted row's bytes actually survive under different maintenance calendars and bucket settings. Eighty-two runs. Persistence checked by listing object versions, never by trusting metadata. Under documented defaults and the retention most deployments actually set, the bytes outlived the delete by 34 days against a 30-day window.

Then the result that changed how we think about this. We expected compaction to dominate, because compaction is what the entire ecosystem optimises: merge-on-read, deletion vectors, better clustering, smarter schedulers. Compaction turned out to be four of the thirty-four days. Everything else is waiting on snapshot expiry, on an orphan-cleanup job somebody deferred, and finally on a bucket lifecycle rule that lives in a different system under a different team's control. The work being poured into the first stage is competing for a quarter of a day.

We tested this the boring way, one variable at a time on the same table. Change the delete mode and the total moves by a day. Deletion vectors are genuinely worth adopting, and they rewrite far fewer bytes, but they will not move a compliance deadline and this talk will show you why the reason is structural rather than tunable. Change the data layout and the total does not move at all. Change one setting in the bucket and it runs from about a month to never finishing. That last sentence is not a figure of speech. There are two configurations where physical erasure cannot complete, one of them is the default posture of a brand-new bucket on a major cloud, and in the other not even the account root can delete the object.

There is a trap in how retention gets expressed, too. One popular table format counts its retention in commits rather than in days, which means the same unchanged configuration erases within hours on an hourly pipeline and takes ten days when someone moves that pipeline to nightly. No setting changed. No alert fired. The SLA moved by a factor of twenty-five. The general lesson outlives the specific product: any floor denominated in something other than time will drift against a deadline that is denominated in time, silently.

The money compounds quietly alongside it. Superseded object versions that no rule ever expires do not plateau, they accumulate, so the carry roughly triples between year one and year two on a petabyte-scale table. The fix is a few lines of JSON, and it is the cheapest line item in the whole talk.

None of this requires you to take our word for it, because the useful part is arithmetic rather than measurement. There is a two-term check you can run against your own tables during the session, from numbers you already know, that tells you whether your window is reachable at all. If it fails, no compaction policy, no table format and no delete mode will rescue you, and knowing that before you spend a quarter tuning a scheduler is worth the twenty minutes. If it passes, we will show you what coordinated scheduling buys on top: pulling every stage forward against the deadline instead of running each on its own cadence took our median from 34 days to 20, at a fraction of the rewrite budget the naive policy needed. We will also tell you what it costs, because it is not free.

We are explicit throughout about what was executed and what was not. The Iceberg chain was measured on real tables. The Delta and Hudi chains are read off their documentation and labelled as such. The cost figures are a model with its assumptions on the slide. Workloads are synthetic and time is virtual, so the day counts are lower bounds; at real scale the jobs take longer, not less.

This is for anyone who operates a lakehouse and has ever been asked to prove that a deletion actually happened: data platform and infrastructure engineers, the people who own compaction and vacuum schedules, and anyone whose name is on a data-retention commitment. You do not need to have read the papers. You do need to have shipped something to production and cared what happened next.

You will leave with a decomposition of where your own erasure latency actually goes, a way to measure residency on your buckets instead of inferring it, the feasibility check to run before touching a scheduler, and four things to look at on Monday morning. One of them takes about ten minutes and removes a liability that currently has no upper bound.

A delete is a promise about visibility. Erasure is a promise about bytes. Only one of them is scheduled by your table format.