Learn / Snowflake

How to delete PII in Snowflake (and actually prove it).

Running a DELETE on your users table feels like erasure. In Snowflake it usually isn't: the data survives in Time Travel, in the mandatory Fail-safe period, in zero-copy clones, and in derived tables — and you are left with no evidence. Here is why, and the crypto-shredding approach that deletes and proves in one call.

Snowflake integrationHow crypto-shredding works →
Why DELETE isn't enough

Four reasons a DELETE falls short in Snowflake.

Time Travel keeps a copy

Snowflake retains prior versions of table data through Time Travel — configurable up to 90 days on Enterprise and above. A row you DELETE stays recoverable, and readable, for that window.

Fail-safe extends it further

After Time Travel expires, a mandatory 7-day Fail-safe period follows for permanent tables, during which the data still exists and can be recovered — with no customer-facing opt-out.

Zero-copy clones don't inherit the delete

A CREATE TABLE ... CLONE shares the source table's micro-partitions as they existed at clone time. A clone taken before the DELETE keeps the original data untouched by anything done to the source afterward.

No evidence is produced

A completed query leaves a log line, not an audit artifact. When a regulator asks what was deleted, when, and how completely, a query history does not answer the question.

The approach

Encrypt on write, destroy the key on request.

The reliable pattern is crypto-shredding. Before personal fields land in Snowflake, encrypt each one with a per-user data encryption key. The warehouse — and everything downstream of it — then stores ciphertext. Staging tables, marts, exports, zero-copy clones, Time Travel, and Fail-safe all inherit that protection automatically, because they only ever held encrypted bytes.

When a deletion request arrives, you do not chase rows across every clone and retention window. You destroy the per-user key in Cloud KMS. Every copy encrypted under that key becomes mathematically unreadable at the same instant, regardless of which table, clone, or retained snapshot it sits in. One KMS operation replaces the fleet of DELETE statements you would otherwise have to locate, run, and somehow prove.

End to end

Deleting a user's PII in Snowflake with proof.

01 / Ingest encrypted

The pipeline encrypts each PII field with the user's DEK before writing to Snowflake. Plaintext never lands in the warehouse.

02 / Map with a registry

A live registry records which columns and which dbt-derived models hold that user's encrypted data, establishing deletion scope without a manual hunt.

03 / Shred the key

On request, the key vault destroys the DEK in KMS. Every encrypted copy — including copies in Time Travel, Fail-safe, and zero-copy clones — becomes unreadable simultaneously.

04 / Issue the certificate

A signed record captures the key fingerprint, the destruction timestamp, and the lineage of covered systems. That is the evidence you hand to an auditor or a DSAR.

Proof record
# deletion proof (decoded)
warehouse: Snowflake
keyFingerprint: sha256:a1b2c3d4e5f6...
shredDate: 2026-07-24T11:03:21Z
covered: raw_users, stg_users, dim_users, mart_customer_metrics
timeTravel: ciphertext_unreadable
failSafe: ciphertext_unreadable
status: certificate_issued
FAQ

Common questions

How do I delete a user's PII from Snowflake for GDPR?

You can run DELETE statements, but they leave copies in Time Travel, the mandatory Fail-safe period, and any zero-copy clones taken before the delete, and they produce no evidence. The reliable approach is crypto-shredding: encrypt PII with a per-user key on write, then destroy that key on request, which renders every encrypted copy unreadable at once and produces a proof certificate.

Do Time Travel and Fail-safe keep deleted data in Snowflake?

Yes. Time Travel keeps prior versions of table data for a configurable window (up to 90 days on Enterprise and above), and Fail-safe adds a further mandatory 7-day retention period after that. Crypto-shredding sidesteps this because the retained versions contain ciphertext that is useless once the key is destroyed.

What happens to zero-copy clones made before the delete?

A clone shares the source table's micro-partitions as they existed at clone time, so deleting a row in the source afterward does not touch the clone's copy. Because Chameleon encrypts on write, the clone only ever held ciphertext in the first place — destroying the per-user key makes that copy unreadable too, without a separate cleanup step per clone.

Why not just DELETE the rows and drop the derived tables and clones?

You would have to enumerate every derived table, clone, and export that copied the data, run a delete or drop against each, wait out Time Travel and Fail-safe, and still have no single artifact proving completeness. Key destruction covers all copies in one operation and emits that proof automatically.

Keep reading