Right to Erasure in Vector Databases and RAG (2026)

Q: Are vector embeddings personal data under GDPR?

Usually yes, when they are derived from text about an identifiable person and linked to that person through chunk metadata. Research on embedding inversion shows embeddings can be partially reconstructed into text, which makes the argument that vectors are anonymous numbers hard to sustain. The EDPB's 2025 enforcement findings also criticised weak anonymisation used in place of deletion.

Q: Does calling delete on a vector database erase the data?

Not immediately. Most vector stores implement delete in two phases: a logical delete that marks the point and hides it from queries, then a physical removal when compaction, vacuum or a segment rebuild runs. Until that second phase, the bytes remain on disk. Erasure is only complete when physical removal happens and every other copy is also gone.

Q: When does Qdrant physically remove deleted vectors?

Qdrant's default configuration runs vacuum optimisation on a segment when at least 20 percent of its vectors are deleted (deleted_threshold 0.2) and the segment holds at least 1,000 vectors (vacuum_min_vector_number 1000). A single person's few dozen chunks in a large segment will not cross that threshold on their own, so erasure needs scheduled or forced optimisation.

Q: How do you erase deleted rows from a pgvector HNSW index?

Deleted rows become dead tuples that remain in the table and index pages until VACUUM runs. The pgvector README notes that vacuuming HNSW indexes can take a while and recommends running REINDEX INDEX CONCURRENTLY before VACUUM to speed it up. For erasure, schedule that sequence on tables with pending requests and record completion in a deletion ledger.

Q: Where else does personal data live in a RAG system besides the vector index?

In the source chunk store and its object versions, index snapshots and backups, semantic or response caches, prompt and trace logs, re-ranker logs, hand-copied evaluation and golden sets, generated derivative documents and any fine-tuned model weights. Each copy needs its own deletion step and evidence, which is why a per-copy deletion ledger matters more than the vector delete call.

Q: How should backups be handled for right-to-erasure requests in vector stores?

Either surgically clean them (restore, delete, compact, re-snapshot, destroy the old copy), which is realistic only for small indexes, or keep a short fixed backup retention such as 35 days plus a restore guard that replays the deletion ledger before any restored index serves traffic. Keeping backups indefinitely without either control is not defensible.

Q: Does crypto-shredding solve erasure for vector databases?

Only partly. Encrypting each subject's payload with a per-subject key and destroying the key works for payload text and metadata, including in backups. It does not work for the vectors themselves, because the index must compute distances on plaintext vectors. Crypto-shredding leaves an orphaned and potentially invertible vector, so it complements compaction rather than replacing it.

Q: What should a DPO ask the engineering team before signing off an erasure request?

Ask for the lineage lookup that found every document and point ID, the deletion ledger showing each copy's state, evidence that compaction ran on affected segments, a probe query showing the subject's text no longer returns their chunks, the backup expiry date or cleaning record, and the vendor's written physical-removal commitment for any managed store.

Satyam Kumar

Zurück zum Blog

architecture

Right to Erasure in Vector Stores: Delete Is a Request, Erasure Is a Proof, So Design the Purge Path Before the First Embedding (2026)

By Satyam KumarOctober 17, 202612 min read

right to erasure gdpr article 17 vector database deletion rag gdpr compliance delete embeddings hnsw tombstones vector index compaction pgvector vacuum qdrant delete points pinecone delete data subject requests backup erasure edpb right to erasure embeddings personal data ai data protection privacy engineering

Right to Erasure in Vector Stores: Delete Is a Request, Erasure Is a Proof, So Design the Purge Path Before the First Embedding (2026)

Frequently Asked Questions

Artikel teilen

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

KI & Cloud Architekt. Ich helfe Teams, Systeme zu bauen, die auf Millionen skalieren.

LinkedIn GitHub

Right to Erasure in Vector Stores: Delete Is a Request, Erasure Is a Proof, So Design the Purge Path Before the First Embedding (2026)

Frequently Asked Questions

Artikel teilen

Comments

Leave a comment