Deleting Your Account: What Actually Gets Erased From Drive, Table by Table

Most vendors answer "what happens to my data when I delete my account" with a sentence: "your data is deleted." That's a policy statement, not a mechanism, and it leaves the actual question unanswered — deleted from where, specifically, and how do you know something wasn't missed? Piskes Drive's account-deletion path is worth describing at the level of what's actually tested, because that level of specificity is rare in this kind of content and it's the thing that actually answers the question.

What's being tested, and why that's the interesting part

Drive's erasure behavior is exercised by a test suite (frontend/apps/drive/src/lib/drive/gdpr.test.ts) against a defined list of tables scoped for erasure. The obvious tables are the ones you'd guess without thinking hard — the documents themselves, the files, the folders. What's more interesting, and what the test suite specifically calls out, are two tables that are easy to get wrong:

drive_trash — documents you already deleted before deleting your account entirely. It's an intuitive mistake to assume something already in the trash is "already gone" and therefore not a separate concern for an account-deletion sweep. It isn't gone — it's still sitting in a trash table, and Drive's erasure logic specifically checks that account deletion clears it too, rather than leaving already-deleted-but-not-yet-purged content behind as an orphan.

docs_templates — a table carrying a scope column from an earlier era of the app's schema. This is exactly the kind of table a less careful erasure sweep misses: not part of the obvious "your documents" set, but still capable of holding data tied to your account if it was scoped that way at some point in the schema's history. Testing against it directly is a sign the erasure list was built by checking the actual schema, not by listing the tables someone remembered off the top of their head.

The honest scope of this claim

This piece is describing Drive's own erasure list specifically — the tables under Drive's ownership that get swept when an account is deleted. There's a broader, platform-wide GDPR effort spanning many more tables across the whole product, and that number has been measured before, but it's not repeated here, because a platform-wide figure needs its own re-check rather than being quoted from memory into an unrelated piece. What's described here is what Drive's own test suite actually exercises, which is the level of specificity this kind of claim should be held to.

Why this level of detail is the actual differentiator

A policy statement that says "your data is deleted" tells you what a vendor intends. A test suite that specifically checks two named tables that a casual sweep would plausibly miss tells you the deletion path was built by someone thinking carefully about the schema's actual shape, edge cases included. For anyone doing due diligence before trusting a platform with data they might later need erased — and that's exactly the audience that reads this kind of content — the second kind of evidence is the kind that actually moves the decision.