Vektordatenbank-Löschung: Ihr delete() löscht nichts

Was Ihr delete() in der Vektordatenbank wirklich tut

Die ehrliche Antwort zuerst, denn genau sie fehlt in fast allen Texten zum Thema: In einem HNSW-basierten Speicher ist delete() eine Operation auf der Sichtbarkeit, nicht auf dem Speicher. Der Eintrag wird markiert und aus den Suchergebnissen ausgeblendet. Der Vektor selbst bleibt in der Segmentdatei liegen, bis ein ganz anderer Vorgang — die Compaction — beschließt, diese Datei neu zu schreiben.

Qdrant schreibt das in der eigenen Dokumentation unverblümt hin: Einträge werden nicht sofort gelöscht, sondern als gelöscht markiert und bei künftigen Abfragen ignoriert. Das ist kein Pfusch, sondern eine bewusste Entscheidung. Einen Knoten aus einem HNSW-Graphen zu entfernen bedeutet, sämtliche Nachbarn zu finden, die auf ihn zeigen, und deren Kanten neu zu verdrahten, damit der Graph zusammenhängend bleibt. Das ist teuer. Also verschiebt es jede ernstzunehmende Engine und erledigt es später gebündelt.

Und hier liegt der Punkt, den niemand aufschreibt: „Später“ ist kein Versprechen, sondern ein Schwellwert.

Löschen ist eine Scheduler-Entscheidung, keine API-Entscheidung

Der Vacuum-Optimizer von Qdrant läuft unter zwei Bedingungen — beide konfigurierbar, beide mit Standardwerten, die die meisten Teams nie öffnen: deleted_threshold (Standard 0.2), der minimale Anteil gelöschter Vektoren in einem Segment, ab dem sich eine Optimierung überhaupt lohnt, und vacuum_min_vector_number (Standard 1000), die Mindestzahl an Vektoren, die ein Segment enthalten muss, um in Betracht zu kommen.

Rechnen Sie einen echten Löschantrag dagegen. Eine Kundin verlangt die Löschung ihrer Daten. Sie finden ihre sieben Chunks, löschen sie, die API quittiert. Diese sieben Vektoren liegen in einem Segment mit 200.000 weiteren. Der Anteil gelöschter Vektoren beträgt 0,0035 Prozent. Der Schwellwert liegt bei 20 Prozent. Der Optimizer sieht sich das Segment an, kommt zum Ergebnis, dass hier nichts zu tun ist, und geht weiter — und er wird zu diesem Ergebnis weiterhin kommen, bis zufällig genug andere Schreiblast das Segment über ein Fünftel Löschanteil hebt. Bei einer stabilen Wissensbasis kann dieser Tag nie eintreten.

Realitätscheck pro Datenbank

Der Mechanismus unterscheidet sich je nach Engine, die Richtung nicht. Das ist die Lage:

• Qdrant — Tombstones plus der oben beschriebene Vacuum-Optimizer. Die gute Nachricht: Die Schwellwerte sind explizit, lesbar und pro Collection einstellbar. Qdrant gehört damit zu den wenigen Stores, in denen Sie Compaction wirklich steuern und beobachten können.
• Chroma — delete() aktualisiert die Metadaten in SQLite, sodass Abfragen den Eintrag überspringen; die HNSW-Indexdatei wird nicht neu geschrieben. Ein gemeldetes Problem zu Version 0.6.3 zeigte, dass die Datenbank nach dem Löschen von Dokumenten sogar wuchs — die Inhalte lagen weiterhin in der Tabelle embeddings_queue, im Klartext samt Embeddings. Ein Pruning des HNSW-Index war zuletzt ein offener Feature-Wunsch, keine zugesicherte Eigenschaft.
• FAISS — für HNSW-Indizes existiert überhaupt kein echtes Löschen. remove_ids unterstützen Indextypen wie IndexFlat, IndexIVFFlat und IDMap (bei IVF muss die Direct Map aktiv sein); für HNSW lautet die dokumentierte Antwort: Index neu bauen. FAISS ist eine Bibliothek, keine Datenbank — die Löschung ist Ihre Aufgabe, nicht ihre.
• Weaviate — Löschungen schreiben Tombstones, die ein periodischer Cleanup entfernt. Gesteuert wird er über cleanupIntervalSeconds am Vektorindex sowie die Umgebungsvariablen TOMBSTONE_DELETION_CONCURRENCY und TOMBSTONE_DELETION_MIN_PER_CYCLE / MAX_PER_CYCLE. Ein Takt, den Sie setzen, ist besser als ein Schwellwert, den Sie vergessen — Ihr Delete-Aufruf ist es trotzdem nicht.
• pgvector — Sie erben das MVCC-Verhalten von PostgreSQL. DELETE macht aus der Zeile ein totes Tupel; ein einfaches VACUUM gibt den Platz zur Wiederverwendung frei, aber nicht an das Betriebssystem zurück; erst VACUUM FULL schreibt die Tabelle neu. Der HNSW-Index muss zusätzlich den Graphen um jeden entfernten Knoten herum neu verdrahten — das ist der eigentliche Kostentreiber. Warum pgvector trotzdem meist die richtige Wahl ist, steht in unserem Überblick zu Vektordatenbanken.

Was übrig bleibt, ist keine anonyme Zahlenreihe

Ein häufiger Einwand an dieser Stelle: Gut, ein Float-Array liegt herum — na und? Lesbarer Text ist das nicht.

Es ist näher an lesbarem Text, als dieses Argument unterstellt. Morris et al. von der Cornell University haben mit Vec2Text („Text Embeddings Reveal (Almost) As Much As Text“, arXiv:2310.06816) gezeigt, dass sich Embeddings invertieren lassen, indem iterativ Kandidatentexte erzeugt und neu eingebettet werden: 92 Prozent der Eingaben mit 32 Tokens wurden exakt rekonstruiert, aus klinischen Notizen fielen vollständige Namen heraus.

Im Juni 2026 hat sich eine Arbeit genau dieses Problems angenommen. „Ghost Vectors“ (arXiv:2606.18497) hat drei HNSW-Implementierungen untersucht und bestätigt, dass soft-gelöschte Vektoren physisch rekonstruierbar bleiben, wenn man die rohen Indexdateien auf der Speicherebene liest — unter Umgehung der API. Mit Vec2Text, ohne domänenspezifisches Fine-Tuning, wurden aus einem Wikipedia-Datensatz zu lebenden Personen 25,5 Prozent der exakten Personennamen und 46,4 Prozent der Ortsangaben wiederhergestellt; bei strukturierten medizinischen Daten lag die Wiederherstellung von Alters- und Geschlechtsmerkmalen bei 100 Prozent. Der Rest im Speicher ist also kein Rauschen. Es ist die Person, leicht verwischt, lesbar für jeden mit Dateizugriff.

Was die Aufsicht annimmt — und wo die Prämisse bricht

Die Datenschutzkonferenz hat im Oktober 2025 ihre Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode (Version 1.0) veröffentlicht. Zur Löschung heißt es dort in Abschnitt 3.5:

Seien Sie fair zur DSK, denn das Papier ist an anderen Stellen sorgfältig und der Satz ist nicht falsch. Einträge in einer Vektordatenbank sind direkt adressierbar — genau diese Eigenschaft macht RAG beherrschbarer als ein feinjustiertes Modell. Die DSK hebt sich ihre Skepsis ausdrücklich für das Sprachmodell auf und hält fest, dass die Probleme bei der Datenlöschung im Sprachmodell ungeachtet der Vorteile eines RAG-Systems bestehen bleiben. Die Einordnung von RAG als datenschutzfreundlichere Architektur teilen wir.

Der Bruch ist enger und technischer als „die Aufsicht irrt“. Adressierbarkeit ist eine Eigenschaft der Schnittstelle. Löschung ist eine Eigenschaft des Speichers. Die Formulierung beschreibt ein System, in dem das Entfernen eines Eintrags und das Entfernen der Daten derselbe Vorgang sind — was für eine Zeile in einer klassischen Datenbank zutrifft und für einen Vektor in einem HNSW-Segment nicht. Ein Verantwortlicher, der Abschnitt 3.5 wörtlich nimmt, ruft delete() auf, dokumentiert, dass der Eintrag aus dem Index verschwunden ist, und hält die Sache nachvollziehbarerweise für erledigt. Er irrt — und die Formulierung warnt ihn an keiner Stelle.

Wer argumentieren will, der verbliebene Vektor sei kein personenbezogenes Datum mehr, führt keine Löschdebatte mehr, sondern eine Anonymitätsdebatte — gemessen an Erwägungsgrund 26 DSGVO und den „Mitteln, die nach allgemeinem Ermessen wahrscheinlich genutzt werden“. Die Stellungnahme 28/2024 des EDSA betrifft trainierte KI-Modelle, nicht Vektordatenbanken, und ist hier daher nicht unmittelbar anwendbar; sie zeigt aber, wie Aufsichtsbehörden diesen Test anlegen: Randnummer 43 verlangt, dass die Wahrscheinlichkeit der Extraktion für jede betroffene Person „unerheblich“ ist, und die zugehörige Fußnote zählt die Extraktion mit wenig oder gar keiner Nutzung der Abfrageschnittstelle ausdrücklich dazu — genau das ist das Auslesen der Indexdatei. Gegen veröffentlichte Inversionsergebnisse lässt sich das schwer behaupten.

Und Art. 12 Abs. 3 DSGVO gibt Ihnen einen Monat für die Beantwortung. Nicht einen Monat plus die Zeit, bis sich das Segment zufällig füllt.

So löschen Sie tatsächlich

Compaction erzwingen — und danach messen

Das Muster ist überall dasselbe: löschen, das Neuschreiben erzwingen, anschließend die Speicherebene zurücklesen und bestätigen. Verlassen Sie sich nie darauf, dass der Hintergrundjob es erledigt hat.

• Qdrant — Punkte löschen, dann das Segment qualifizieren: Jede Update-Operation auf der Collection stößt die Optimizer an, und über die Optimizer-Konfiguration der Collection lassen sich deleted_threshold und vacuum_min_vector_number vorübergehend so verschärfen, dass auch eine kleine Löschung die Hürde nimmt. Segment-Statistiken vorher und nachher auslesen, danach die normalen Schwellwerte wiederherstellen.
• pgvector — DELETE, anschließend VACUUM FULL, wenn die Tabelle physisch neu geschrieben werden muss, und REINDEX für den HNSW-Index. Der Preis gehört dazugesagt: VACUUM FULL nimmt eine exklusive Sperre und schreibt die gesamte Tabelle neu. Das ist eine Wartungsfenster-Operation, nichts, was Sie auf Zuruf auslösen.
• Weaviate — der Tombstone-Cleanup-Zyklus ist der Hebel. Stellen Sie sicher, dass sein Intervall kurz genug ist, damit eine Löschung innerhalb Ihrer Antwortfrist physisch bereinigt wird, und dass die Limits pro Zyklus ihn auf einem großen Index nicht stillschweigend aushungern.
• Chroma und FAISS — hier gibt es keinen erzwingbaren Compaction-Pfad, auf den Sie sich stützen sollten. Der belastbare Weg ist, Collection oder Index ohne den betroffenen Chunk aus der Quelle neu zu bauen, umzuschalten und die alten Dateien zu vernichten. Behandeln Sie „Neubau“ als das Löschverfahren und planen Sie den Aufwand ein.

Was ich nicht tun würde: deleted_threshold global auf nahezu null setzen, damit „Löschungen immer compacten“. Sie zwingen den Optimizer auf einer aktiven Collection zum Dauer-Neuschreiben und zahlen das dauerhaft in Latenz und I/O — für einen Vorgang, der Sie ein paar Mal im Jahr erreicht. Erzwingen Sie es pro Antrag, weisen Sie es nach, setzen Sie die Schwellwerte zurück.

Wenn Sie nicht erzwingen können: kryptografische Löschung

Wo sich Compaction nicht erzwingen lässt — ein Append-only-Index, ein unveränderliches Backup, ein Store ohne entsprechenden Schalter — bleibt der Weg, die Bytes unbrauchbar statt abwesend zu machen. Verschlüsseln Sie Vektoren mit einem Schlüssel, der zu einer Epoche oder zu einer betroffenen Person gehört, und vernichten Sie den Schlüssel bei der Löschung. Die Autoren von „Ghost Vectors“ setzen genau das als Epoch Key Rotation um: rund 0,005 ms pro Datensatz, Wiederherstellung personenbezogener Daten auf null, dazu ein signierter kryptografischer Nachweis des Löschvorgangs.

Die Grenzen gehören ausgesprochen. Kryptografische Löschung ist nur so stark wie Ihre Schlüsselverwaltung: Überlebt eine Kopie des Schlüssels im Backup des Key-Vaults, in einem Escrow oder in einem alten KMS-Snapshot, haben Sie nichts vernichtet, sondern nur dokumentiert, dass Sie es vorhatten. Ein Schlüssel pro Epoche liefert außerdem Epochen-Granularität, keine Personen-Granularität — für eine einzelne Person müssen Sie pro Person schlüsseln, was kostet, oder die Epoche neu verschlüsseln. Und ob eine Aufsichtsbehörde die kryptografische Löschung als Löschung im Sinne des Art. 17 anerkennt oder als bloße Sicherheitsmaßnahme wertet, ist nicht einheitlich geklärt. Behandeln Sie sie als Antwort dort, wo physisches Neuschreiben unmöglich ist — nicht als bequemen Standardweg.

Die Flächen, die alle vergessen

Das Compacten des Live-Segments ist der Teil, an den alle denken, und die kleinere Hälfte der Arbeit. An den Kopien scheitern Löschanträge tatsächlich:

• Snapshots — ein Snapshot von vor der Löschung enthält den Vektor vollständig und unmarkiert. Das Löschen in der Live-Collection ändert daran nichts.
• Replikate — jeder Knoten hat eigene Segmente und einen eigenen Optimizer-Zustand. Compaction auf dem Leader ist keine Compaction auf dem Follower.
• Backups — vor allem inkrementelle, in denen der gelöschte Vektor in der Kette früherer Inkremente unbehelligt weiterlebt. Hier verdient die kryptografische Löschung meist ihr Geld.
• Write-Ahead- und Ingestion-Logs — der oben genannte Chroma-Fall ist das Lehrbuchbeispiel: aus dem Index verschwunden, in einer Queue-Tabelle im Klartext weiterhin vorhanden.
• Retrieval-Logs — die meisten RAG-Systeme protokollieren die abgerufenen Top-k-Chunks für Debugging und Evaluation. Dieses Log ist eine Klartextkopie genau der Passage, die Sie gerade gelöscht haben.
• Gespeicherte Modellausgaben — gesicherte Dialoge, in denen der Assistent den Chunk wörtlich zitiert hat. Der Vektor ist weg; die Antwort, die ihn wiedergibt, steht weiterhin in Ihrer Chatverlauf-Tabelle.

Nichts davon ist exotisch. Es ist die normale Folge eines Systems, das Daten aus guten Gründen kopiert — und der Grund, warum Löschung eingeplant und nicht nachgerüstet werden muss. Dasselbe Argument machen wir für die DSGVO als Architekturfrage.

Der Löschnachweis: Was der Datenschutzbeauftragte vorlegt

Wenn eine Aufsichtsbehörde fragt, wie Sie den Antrag umgesetzt haben, ist „wir haben den Delete-Endpunkt aufgerufen, er hat 200 zurückgegeben“ kein Nachweis. Es ist eine Aussage über eine API. In die Akte gehört ein Datensatz, der die Speicherebene vorher zeigt, die erzwungene Compaction dazwischen und die Speicherebene danach — signiert, damit er später nicht stillschweigend nachgebessert werden kann.

{
  "antrag_id": "ART17-2026-0142",
  "betroffener_ref": "hmac-sha256:9f2b8c...e41d",
  // gekeytes Pseudonym, nicht der Name — ein blanker
  // Hash waere brute-forcebar. Bleibt personenbezogen.
  "eingegangen_am": "2026-07-02T09:14:00Z",
  "rechtsgrundlage": "Art. 17 Abs. 1 lit. a DSGVO",
  "collection": "kb_support_de",
  "chunks_betroffen": 7,
  "api_delete": {
    "am": "2026-07-02T09:31:12Z",
    "wirkung": "tombstoned — noch nicht physisch entfernt"
  },
  "segmente_vorher": [
    {"id": "seg-a1", "vektoren": 200000, "geloescht": 7}
  ],
  "compaction": {
    "erzwungen": true,
    "methode": "Schwellwerte gesenkt, danach zurückgesetzt",
    "beendet_am": "2026-07-02T09:48:57Z",
    "segmente_neu_geschrieben": ["seg-a1"]
  },
  "segmente_nachher": [
    {"id": "seg-b7", "vektoren": 199993, "geloescht": 0}
  ],
  "nachgelagert": {
    "replikate_bestaetigt": ["node-1", "node-2"],
    "snapshots_vernichtet": ["snap-2026-06-30"],
    "backups": {"methode": "krypto-loeschung",
                "schluessel_epoche": "2026-Q2",
                "schluessel_vernichtet_am": "2026-07-02T10:02:00Z"},
    "retrieval_logs_bereinigt": true,
    "ausgaben_geschwaerzt": 2
  },
  "geprueft_von": "l.friedrich",
  "signatur": "ecdsa-p256:MEUCIQD..."
}

Tragend sind die Zeilen segmente_vorher, compaction und segmente_nachher. Alles andere ist Kontext. Diese drei machen aus „wir haben gelöscht“ ein „dieses Segment enthielt den Datensatz, wir haben das Neuschreiben zu diesem Zeitpunkt erzwungen, und das neu geschriebene Segment enthält ihn nicht mehr“. Das ist ein Löschnachweis, den ein Datenschutzbeauftragter einer Aufsichtsbehörde vorlegen kann.

Damit kommen wir zum unbequemen Teil. Um das zu erzeugen, müssen Sie Segment-Statistiken lesen, die Optimizer-Konfiguration ändern, Ihre Replikate und Snapshots aufzählen und Backup-Schlüssel vernichten können. Bei einem verwalteten, mandantenübergreifenden Vektordienst bekommen Sie in der Regel eine API-Quittung und einen Auftragsverarbeitungsvertrag — keinen Nachweis auf Segmentebene, den Sie unterschreiben würden. Manche Anbieter legen mehr offen als andere, und danach zu fragen gehört in jede Beschaffung; die belastbare Fassung dieses Artefakts braucht aber Zugriff auf die Speicherebene. In der Praxis heißt das: dort betreiben, wo Ihnen die Platte gehört.

Und die ehrliche Grenze des Nachweises selbst: Er belegt, dass das Segment neu geschrieben wurde. Er belegt nicht, dass nie eine Kopie das Haus verlassen hat — ein Export auf einen Laptop, ein Debug-Dump, ein Screenshot. Ein Löschnachweis begrenzt, was Ihr System getan hat. Was Ihre Leute getan haben, begrenzt er nicht.

Wo Tippel ins Spiel kommt

Die meisten RAG-Systeme sind so gebaut, dass sich diese Frage im Nachhinein nicht mehr beantworten lässt. Löschnachweise in ein laufendes System nachzurüsten ist deutlich teurer, als am ersten Tag zu entscheiden, welcher Store zum Einsatz kommt, wo er läuft, was protokolliert wird und wie eine Löschung erzwungen und festgehalten wird. Diese Entscheidung kostet am Anfang einen Nachmittag und am Ende ein Projekt.

Wenn Sie ein RAG-System mit personenbezogenen Daten betreiben oder planen und wissen möchten, ob Sie einen Antrag nach Art. 17 heute tatsächlich beantworten könnten, ist das eine konkret prüfbare Frage — und genau dafür gibt es unseren KI-Readiness-Check: an Ihrem System, mit schriftlichem Urteil. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.

Dies ist Engineering-Beratung, keine Rechtsberatung. Wie Art. 17 auf Ihre Verarbeitung anzuwenden ist, klären Sie mit Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung; was Ihre Speicher-Engine physisch mit den Bytes macht, klären Sie mit Ihrem Engineer — und um diese Hälfte geht es hier.