Time Travel and Snapshots as Compliance Tools: GDPR Deletes in the Lakehouse

A lakehouse’s time-travel capability — querying data exactly as it existed at a past point in time — is marketed as an analytics and debugging feature. It’s also, less obviously, a genuine compliance liability if nobody has thought through what it means for a GDPR erasure request, because a snapshot preserving deleted data’s prior state is, structurally, a copy of exactly the data an erasure request was supposed to remove.

I’ve written about the right to erasure in systems with backups and event logs generally. Lakehouse time-travel and snapshotting is a specific, increasingly common technical case of exactly that tension — a genuinely valuable feature, built on table formats like Iceberg and Delta Lake, that most organisations adopting it haven’t fully reasoned through from a data-protection angle.

Why time-travel and erasure are structurally in tension

Modern lakehouse table formats retain historical snapshots specifically so a query can reconstruct the table’s exact state at a past point in time — genuinely valuable for debugging a data pipeline issue, auditing a historical calculation, or recovering from an accidental bad write. That same mechanism means a record deleted from the current table state can remain fully queryable through a snapshot taken before the deletion, for as long as the format’s retention policy keeps that snapshot alive — which, by default in many implementations, can be considerably longer than an organisation’s actual GDPR erasure obligations would tolerate.

What this means in practice

A “deleted” record in a lakehouse table, without deliberate configuration, is frequently not actually gone — it’s simply absent from the current view, while remaining fully present and queryable in every snapshot taken before the deletion, until those snapshots are themselves expired according to the table’s retention settings. An organisation that processed a genuine erasure request, confirmed the record no longer appears in normal queries, and considers the matter closed may still be retaining the deleted data in queryable form for weeks or months, entirely legitimately from the table format’s own design intent, and entirely in tension with what the erasure request actually required.

What genuinely resolving this requires

Explicit snapshot expiration policies, tuned to actual compliance requirements, not left at whatever default the table format ships with — a genuine, deliberate retention window for historical snapshots, short enough to satisfy erasure obligations within a reasonable timeframe, rather than assumed to be someone else’s problem because the feature exists primarily for analytics.

Genuine snapshot expiration triggered by erasure events specifically, not just a time-based schedule — a table’s snapshot retention policy running purely on a calendar basis will retain a just-deleted record in historical snapshots for however long the schedule specifies, regardless of when an actual erasure request landed; a more deliberate process can trigger expedited snapshot cleanup specifically when an erasure request affects data present in retained snapshots.

Documentation reflecting how the specific table format’s time-travel actually behaves, as part of the genuine erasure process I’ve written about generally — an organisation’s erasure procedure needs to account for this mechanism explicitly, the same backup-and-event-log discipline extended to a newer, increasingly common data-platform pattern that most existing erasure documentation was written before lakehouse adoption became common enough to require addressing.

What one review actually found

A retail analytics firm processed a genuine erasure request, confirmed the customer’s record no longer appeared in any current query, and closed the request as complete. A subsequent, unrelated data-engineering review discovered the deleted record remained fully queryable through three separate historical snapshots, the most recent taken only two days before the erasure request, with the table’s default retention policy keeping all three alive for another several weeks. The erasure had been genuinely handled at the current-data layer and genuinely incomplete at the snapshot layer — a gap invisible to the compliance team, because nobody involved in the original erasure process knew the lakehouse’s time-travel feature existed, let alone how it interacted with a deletion.

Assessing whether a specific lakehouse deployment’s snapshot and time-travel configuration genuinely satisfies erasure obligations, or is quietly retaining deleted data in a form most compliance teams haven’t examined, is exactly the kind of technical-compliance review a technology control assessment is built to run.

The fix was a genuine, if slightly involved, configuration change — tightening snapshot retention and adding an erasure-triggered cleanup step. Finding the gap in the first place was the harder, more valuable part of the exercise.

This is a specific, increasingly common case of the general tension covered in the right to erasure in systems with backups and event logs.

The firm’s other lakehouse tables, checked afterward using the same question, revealed two more instances of the identical gap — a pattern, not an isolated oversight, once anyone thought to look for it systematically.