How the GDPR right to erasure applies to vector databases
When personal data has been chunked and embedded for retrieval, an erasure request does not end at the source file. The controller must make sure the personal data is removed from the vectors, the payloads that carry the text and metadata, the snapshots taken from the collection, and the backups that still hold any of them. Article 17(1) requires erasure without undue delay where one of six grounds applies: the data is no longer necessary for its purpose, consent is withdrawn, a valid objection is upheld, the processing was unlawful, a legal obligation requires erasure, or the data was collected from a child for information society services. Once the ground is established, the question for the engineering team is which copies of the data exist and where they sit. Article 19 also requires the controller to tell each recipient of the data about the erasure, unless that is impossible or disproportionate.
The EDPB's 2025 coordinated enforcement action on the right to erasure, covering 32 data protection authorities and 764 controllers and announced on 18 February 2026, identified seven recurring challenges. Two bear directly on vector stores: controllers that anonymised data in place of deleting it, and controllers that could not delete personal data held in backups. A vector that is merely hard to link back to a person is not a substitute for deletion unless the controller can show that the data is truly anonymous, so teams should not rely on that argument for embeddings built from identifiable text. Confirm with your data protection officer how your organization classifies vectors derived from personal data before the first request arrives. The EDPB news item on these challenges summarizes the findings.
The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary and does not reduce the controller's responsibility. DeployOpen can design and implement the controls that make erasure traceable: source-to-vector mapping, deletion by identifier across collections and payloads, snapshot and backup retention rules that match the erasure procedure, and logs that show what was removed and when. The evidence those controls produce is still judged by your internal audit function, your independent auditors where they are engaged, and the supervisory authority if it ever asks. Ask any implementation partner to show how deletion is tested on a restored copy, not only on the live collection, and which records their procedure leaves for an assessor to sample.
Mapping erasure obligations to vector store controls
This table maps each GDPR erasure obligation that touches a vector store to the function the store must perform and the configuration that makes it possible. Read each row as a control you must be able to demonstrate, then check the configuration column against your own collection design and snapshot policy.
| Requirement | What the function must do | Configuration to set |
|---|---|---|
| Article 17(1) erasure grounds and response clock | Identify every embedded chunk derived from a person's data once an erasure ground applies, and remove it without undue delay | Stable source record keys in every point payload, so a request can be resolved to chunk IDs in one query |
| Article 19 recipient notification | Record which downstream systems, replicas or exports received the data, and notify them of erasure unless disproportionate | Maintain a register of collections, snapshots and exports per source system, with named owners for each copy |
| Article 58(2)(g) supervisory orders | Produce, on request, proof that specific vectors and payloads were deleted and when | Audit logging of authenticated API operations enabled, with logs retained outside the vector store |
| Article 32 security of processing and deleted-data residue | Limit who can delete, read or export vectors, and prevent deleted data from resurfacing through restores | Admin and read-only API keys, per-collection JWT permissions, TLS on REST and gRPC, and network binding restricted to trusted hosts |
| EDPB backup findings | Make deletion effective in backups by expiring or re-running restores that exclude erased records, and document the rule | Snapshot retention limits with a defined expiry, snapshots stored in controlled S3-compatible buckets, and a restore procedure that replays deletions |
| EDPB anonymisation findings | Delete or re-embed derived content instead of masking it, since vectors that still encode a person remain personal data | Re-embedding pipeline that removes the source chunk and its vector together, with no pseudonymised copies kept as substitutes |
| Deletion evidence for the file | Show the request, the matched source key, the deleted point IDs, the time, the operator and the backup expiry date | Structured log record per erasure job with source key, point count, operator identity and snapshot cycle reference |
Tracing vectors back to the source record
This sequence makes every vector traceable to the source document, data subject and embedding run that produced it, so an erasure request can be resolved to every point and row that holds the data. It is the precondition for every deletion step that follows.
Design the provenance fields in every payload
Before any document is ingested, the data protection lead and the platform architect agree the metadata each chunk carries: a stable source document ID, a data subject reference where processing it under a lawful basis makes that necessary, the embedding model name and version, and an ingestion batch ID. Keep the data subject reference pseudonymous (an internal key, not a name or email address) so the mapping table, not the vector store, holds the identity. The output is a written payload schema signed off by both teams, applied identically to Qdrant points and pgvector rows.
Confirm which fields the platform indexes
Ask the implementation partner to test, on a non-production collection, which payload fields the chosen platform can index and filter on for your query patterns. Storing a field is not the same as being able to find points by it efficiently, so a delete-by-subject query may scan the whole collection if the field is unindexed. Confirm this against the current documentation for your version, and record the result in the design file. Done means a test query on the subject reference returns the expected points within a timed run you define yourself.
Build the register linking subjects to sources
Create a controlled register that maps each data subject reference to the source documents, record IDs and batch IDs where that person's data was ingested. This register lives in the organization's own relational store with restricted access and its own audit trail. It is the starting point for every erasure request, because the vector store alone cannot reliably answer which documents mention a given person. Done means a sample ingestion run produces register entries that a reviewer can reconcile against the source system.
Resolve a request to source documents and batches
When an erasure request arrives, the privacy team confirms the requester's identity and whether any exception applies, then looks up the subject reference in the register. The result is a list of source document IDs and ingestion batch IDs. The request record notes the lookup time and the operator who ran it. Done means the request ticket lists every source document and batch identified, or records that none were found.
Resolve source documents to every vector
Using the source document IDs and batch IDs, the platform team runs filtered queries against each collection to list every point or row derived from those sources. For Qdrant, this is a filter on the payload fields confirmed earlier. For pgvector, the equivalent is a query on the table columns in PostgreSQL, which keeps vectors in the same database as relational records. Include points produced by re-embedding: when a model was upgraded, the old and new vectors may both exist until the old ones are removed, so the query must cover every model version. Done means a saved list of point IDs or primary keys per collection and table, with counts reconciled to the register.
Reconcile the trace and flag gaps
The data protection lead compares the vector list with the register and the source system to find orphans, meaning vectors with no register entry, and missing vectors, meaning source records with no matching points. Orphans usually come from ingestion runs that predate the provenance schema or from failed batches, and they must be handled before the request is closed. Record every discrepancy and its resolution in the request file. Done means the counts agree or each difference has a documented explanation and an action.
Extend the trace to snapshots and backups
Live collections are not the only location. Snapshot archives and backup sets also contain the points and rows, so the trace must record which snapshots and backups hold each batch. Qdrant collection snapshots are tar archives, and a full-storage snapshot covers the whole node. Log the snapshot identifiers and storage locations so the deletion work in later steps can address them. Done means a register of backup locations exists for each collection and table, with retention periods confirmed against your backup policy.
Which self-hosted platforms support erasure workflows
Erasure on a vector store depends on three things: whether the platform can delete points by payload filter, whether access and changes leave an audit trail, and whether snapshots and backups can be scoped and purged. The cards below compare the options most teams shortlist and name the checks to run before committing to one.
Qdrant
Qdrant is Apache-2.0 licensed, and v1.19.2 was published on October 5, 2026. Points can be deleted by payload filter, so a document identifier stored in each payload lets you remove every chunk derived from a source record in one operation. Per-collection JWT permissions have been available since v1.9.0 and JSON audit logging of authenticated API operations since v1.17.0, which gives you evidence of who deleted what. Self-deployed Qdrant listens on all interfaces with no authentication by default, so secure it before loading personal data. The community Helm chart lacks zero-downtime upgrades, so plan maintenance windows for upgrades.
pgvector on PostgreSQL
pgvector is released under the PostgreSQL License, and v0.8.7 was released on October 1, 2026. Because vectors sit in the same database as the relational records they came from, a single SQL transaction can delete a source row and its embeddings together, which removes the reconciliation gap that separate stores create. The README states support for PostgreSQL 13 and later. Confirm that your backups, logical replicas and point-in-time recovery copies can also be purged or excluded for erased subjects, since those copies hold the same vectors.
Milvus
Milvus is a distributed open-source vector database that many teams evaluate at large scale. Confirm against its documentation whether deletion by expression is supported, how soft deletes and compaction affect when removed vectors are physically gone, and whether backup tooling can restore a collection without re-including deleted records. Check the license terms that apply to your deployment model before you standardize on it, and test a full erasure path on a copy of your data.
Weaviate
Weaviate is an open-source vector database with object-level operations and a schema that stores properties alongside vectors. This can simplify tracing a vector back to its source object. Confirm in its documentation how object deletion by property filter behaves, whether deleted objects remain in backups, and which role-based access controls and audit logs are available in the edition you plan to run. Ask your implementation partner to show the erasure runbook working against a backup restore, not only against the live cluster.
Qdrant snapshots on S3-compatible storage
Qdrant collection snapshots are tar archives of one collection on one node, and snapshots can be stored in S3-compatible storage since v1.10.0. Erasure has to reach these archives as well, so keep a register of which snapshots contain which collections and dates, and define how an erased record is removed from retained archives. Full-storage snapshots work only on single-node deployments, which limits the options for distributed clusters. Decide whether you purge archives, restore and re-delete, or document an exception with your data protection lead.
Evidence auditors and DPAs ask for after deletion
This table lists each evidence item an assessor or data protection authority is likely to request after a vector erasure, the component that produces it and the retention rule you must set. Read it as a checklist to build before the first erasure request arrives, not after. The main takeaway is that vector store logs alone rarely prove deletion, because source records, backups and recipient notices each need their own record.
| Evidence item | Produced by | What it shows and retention rule to set |
|---|---|---|
| Erasure request register | Application ticketing or case system | Request date, identity verification, legal basis, decision and reason for any refusal. Set a retention period in your records policy that outlasts the evidence it supports. |
| Source-to-vector mapping export | Ingestion pipeline metadata, stored with the vector payload | Lists every chunk and point ID derived from each source record. Keep it current on each re-embedding and retain it as long as the mapping is needed to find vectors. |
| Deletion query and point count before and after | Vector store query output, run by the operator and saved to the case record | Shows filter used, matched points and remaining count after delete. Store the output with the request ID and keep it with the register entry. |
| Snapshot and backup inventory with purge records | Backup catalogue and snapshot storage listing, such as S3-compatible buckets for Qdrant snapshots | Identifies every snapshot or backup holding the data and when it was expired or rebuilt. Confirm with your backup tool how long copies persist before automatic expiry. |
| Audit log extracts of authenticated delete operations | Vector store audit log (for Qdrant, JSON audit logging of authenticated API operations, v1.17.0 or later) and PostgreSQL logs for pgvector | Shows which identity ran the delete and when. Confirm that logs are forwarded to central storage with a retention rule set by your policy, because local logs rotate. |
| Recipient notices under Article 19 | Correspondence system or ticketing workflow, with a list of downstream recipients | Proof that erasure was communicated to each recipient, or a documented reason why it was impossible or disproportionate. Retain alongside the register entry. |
| Restore test record for backups | Backup and recovery runbook output | Shows that restored environments do not bring back erased points. Ask your partner to document the procedure and the date it was last run. |
What deleting vectors alone does not satisfy
Removing points from the live collection is the visible step, but erasure reaches every copy of the personal data and every place the derived vectors were sent. The cards below cover the copies that most often survive a delete request, and the checks that show whether they were handled.
Snapshots and backups
A deleted point stays in every snapshot and backup taken before the request until that copy expires or is overwritten. Qdrant collection snapshots are tar archives of a collection on one node, and full-storage snapshots apply only to single-node deployments, so a cluster may hold several copies to trace. Ask the team to write down the backup retention period, list where snapshots are stored (including any S3-compatible bucket), and decide how a restore will re-apply pending erasures so deleted people do not reappear. The EDPB's 2025 coordinated enforcement action flagged deletion of personal data in backups as a recurring problem.
Caches, logs and LLM traces
Chunk text and payloads often reappear in application caches, request logs, retrieval traces and LLM observability tools. A query log that records the retrieved passage keeps the personal data even after the vector is gone. Inventory every service that receives retrieved text, set retention on each, and confirm whether the logs contain payload text or only identifiers. Logs that the organization must keep for other reasons, such as the record-keeping duties in the EU AI Act for high-risk systems, need a documented answer for how personal data in them is handled.
Derived artefacts from re-embedding
Re-embedding after a model upgrade, reindexing or a chunking change creates new vectors, intermediate files and staging collections that copy the same source text. Each pipeline run is a processing activity that the erasure process must reach. Check whether temporary collections, export files and embedding batch outputs are deleted after each run, and whether a deletion job can find vectors generated from a source record that has since changed. Confirm this with the team before the first re-embedding run after go-live.
Anonymisation used in place of deletion
Some teams replace identifiers in chunks with tokens or generic labels and then treat the vectors as outside scope. Pseudonymised or partially masked embeddings can still allow a person to be singled out, so this approach may not meet an erasure request. The EDPB identified ineffective anonymisation used instead of deletion as one of seven recurring challenges. Ask the team to show the test used to decide that data is anonymous, and to explain what happens when a request names a person whose details remain in embedded text.
Recipients who were not told
Article 19 requires controllers to notify each recipient to whom personal data was disclosed about the erasure, unless this is impossible or disproportionate. Vector copies sent to an embedding API, a hosted reranker, a managed backup service or a partner's analytics tool are recipients. Keep a current list of processors and downstream systems that received the chunks, and define who sends the notification and how it is recorded. Records that show the notification was sent or why it was not possible are part of the evidence.
Changing rules and status checks
Regulation (EU) 2025/2518 sets additional procedural rules for cross-border enforcement and applies from 2 April 2027, so procedures designed now should be reviewed before that date. The Omnibus IV and Digital Omnibus proposals had not changed the GDPR text as of October 2026, but both are still moving through the EU legislative process. Ask counsel to confirm the current status of each proposal and to schedule a review of the erasure procedure once the legislative position is settled.
Questions buyers ask before deleting personal data from embeddings
Are vector embeddings personal data under the GDPR, and who decides?
Often yes, when the source text identifies or can be linked to a person, because an embedding is derived from that personal data and can be traced back to it through the stored payload. The controller decides, using its own assessment of the source records, the purpose of the search and whether identifiers survive chunking. Your data protection officer or legal team should record that decision, since the GDPR's definition of personal data in Article 4 is applied case by case. A supervisory authority can take a different view, so treat the position as a documented decision rather than a settled fact. DeployOpen can prepare the mapping and evidence that support the decision, but the determination itself stays with your organization.
How long does a deletion take to reach backups and snapshots?
Deletion in the live collection can be immediate in a well-run system, but copies in snapshots and backups persist until they expire or are rotated. The time depends on your retention policy for each copy, which is the main driver. Qdrant collection snapshots are tar archives of a collection on one node, and full-storage snapshots work only on single-node deployments, so each snapshot must be located and handled separately. The EDPB's 2025 coordinated enforcement action identified deletion of personal data in backups as a recurring challenge. Agree a documented rule with your data protection team on how backup copies are handled, such as deleting, expiring or restoring with the erased records excluded, and confirm the exact figures with your backup platform.
What drives the cost and effort of erasing data from embeddings?
The effort follows the number of places the data went, not the number of deletion requests alone. The main drivers are:
- Mapping: how many source systems, chunks and embedding runs link to each person.
- Snapshot and backup retention: how many copies exist and how long each one is kept.
- Re-embedding: whether a model change or a repaired pipeline forces vectors to be regenerated.
- Evidence: how deletion is logged, verified and kept for an assessment.
One-time costs cover the initial mapping and pipeline changes. Recurring costs cover request handling, backup handling and periodic checks. Ask any partner for a quote that lists each driver separately, with the systems in scope and the assumptions about retention.
What do we need from our data protection and platform teams?
The work needs decisions from the data protection team and access from the platform team. Data protection should define which records count as erasure triggers under Article 17(1), how a request is verified, and how recipients are notified under Article 19. Platform engineering should provide read access to the pipeline, the vector store, its snapshot locations and backup policies, plus change windows for production work. Both teams should agree who signs off on each deletion and where the evidence is kept. Without these decisions, the technical deletion has no defined standard to meet.
Can our internal team handle erasure from embeddings alone?
A capable internal team can do it, provided it has the skills and time for the work. The skills include the embedding pipeline, the vector store's API for deleting points and payloads, backup administration, and documentation a compliance reviewer will accept. Check whether the team can trace a vector to its source record, delete the vector and its payload, locate every snapshot and backup containing it, and prove each step happened. Many teams find the first request is manageable but the recurring process, including upgrades and new sources, is where the load grows. Assess this against your current staffing before deciding.
What does a fixed-scope engagement for erasure cover?
A fixed-scope engagement covers the systems, deliverables and timelines agreed in writing before work starts. For erasure, a typical scope includes mapping the vector stores and pipelines in scope, defining how vectors link to source records, implementing or documenting the deletion procedure, handling snapshots and backups under the agreed rule, and producing the evidence your assessors will request. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do. Ask for the scope list, out-of-scope items, handover documents and any ongoing support, which is available as a separate retainer.
Which evidence proves that deletion happened?
Evidence is a record that a specific erasure request was received, assessed, executed across the live store and backups, and communicated to recipients where required. Useful records include the request identifier, the source record references, the deleted point identifiers, the time of deletion, the operator and the backup handling outcome. Qdrant's security documentation describes JSON audit logging of authenticated API operations from v1.17.0, which can support this trail if enabled and retained. Your retention period for the logs should be set with your legal team, and the log store must be protected against tampering. Confirm with your vector store version whether these logs are available before you commit to a design.
How DeployOpen scopes and delivers erasure controls
DeployOpen plans, configures and documents the self-hosted vector store and the erasure workflow around it, inside the client's own cloud accounts, data centers or air-gapped network. In practice that means agreeing which collections hold chunks derived from personal data, how each point's payload links back to its source record and document version, how a deletion request is queued and executed against points, payloads, snapshots and backups, and who approves each step. The work is delivered as a fixed-scope engagement, and the scope, deliverables and timelines are agreed in writing before any configuration begins. Anything not written into that scope, such as re-embedding history or upstream source systems, should be named explicitly so it is not assumed.
Testing is where the design is proven. DeployOpen can exercise the deletion path end to end on a non-production copy: remove a source record, confirm the matching points and payloads disappear from the live collection, and then check that a restore from a snapshot or backup taken before the deletion does not bring the data back into service without the erasure being reapplied. For Qdrant, that means checking which snapshot types the deployment produces, where they are stored, and whether restores are version-matched. Evidence is captured as the tests run, including request records, logs from the authenticated API operations the platform records, and restore test results, so the client holds the material its own assessors will ask for.
DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether an erasure response meets Article 17 in a given case; that judgment stays with the controller and, where relevant, its data protection officer and legal counsel. What DeployOpen provides is the technical control set, the runbooks, the test records and the handover documentation that let the client's own assessors or supervisory authority review the position. Before engaging a partner, ask for the written scope template, the list of deletion test cases, the restore test method, and the named owner for each deliverable.
How DeployOpen delivers erasure-ready vector databases
DeployOpen plans, implements, hardens, documents and supports self-hosted vector databases inside your own cloud accounts, data centers or air-gapped networks. For erasure, the work centers on a written scope that maps where personal data enters the embedding pipeline, and on deletion procedures that reach vectors, payloads, snapshots and backups.
How we scope
- Map which source systems feed personal data into chunking and embedding pipelines, and where each vector is written.
- Agree in writing which deletion paths are covered: live collections, payloads, snapshots, backups and downstream copies.
- Confirm with your legal and privacy team which erasure grounds and recipients the deletion procedure must serve.
How we build
- Configure authentication, per-collection permissions and TLS so only authorized services can delete or query vectors.
- Build a source-to-vector lineage record so each deletion request resolves to point identifiers and collections.
- Test deletion end to end, including restore tests that confirm erased records do not return from snapshots or backups.
How we hand over
- Document the erasure runbook, lineage schema, retention rules for snapshots and backups, and the audit log design.
- Deliver deletion evidence: request identifiers, timestamps, deleted point counts and verification queries for your records.
- Provide a clear split of responsibilities between your team, your auditors and your privacy function for each evidence item.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Re-run deletion and restore tests when the embedding model, chunking logic or vector database version changes.
- DeployOpen prepares systems and evidence for assessments. Independent auditors and certification bodies issue any audit report or attestation.
