You Deleted the Note. Your AI Index Didn't.

Deleting a note removes it from your vault. It does not necessarily remove it from the index your AI assistant searches. That index is derived state — a second copy with its own delete semantics — and in most systems a delete marks a record invalid while the vector stays on disk.

The systems that behave this way document it themselves. hnswlib, the graph library sitting underneath several popular vector stores, describes its delete call as a mark: mark_deleted(label) "marks the element as deleted, so it will be omitted from search results."¹ Weaviate's configuration reference names the leftover directly: "Tombstones are records that mark deleted objects. In an HNSW index, tombstones are regularly cleaned up, triggered periodically by the cleanupIntervalSeconds parameter." The default cleanup interval is 300 seconds.²

An independent measurement agrees with both. A June 2026 preprint that examined three such systems states the general case flatly: "When a user requests data deletion, the systems typically only mark the record as deleted, leaving the embedding on disk physically unchanged."³

None of that is a scandal. It is a defensible engineering decision with a real cost behind it.

It is also invisible from where you sit, which is the whole problem.

Most people assume one copy and one delete

The assumption is reasonable and almost never examined: there is one vault, deleting a note removes the file, the assistant reads the vault, therefore the assistant forgets. Every file manager you have ever used reinforces it. One list, one item, one delete, and the item is gone from the list.

The law encodes the same intuition. GDPR Article 17, titled "Right to erasure ('right to be forgotten')", says the data subject "shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay."⁴ That is context, not legal guidance — this post is not legal advice and takes no position on whether any system meets any obligation.

But erasure is a property of every copy, and retrieval systems make copies as a matter of course. The moment you embed a note, its content becomes a numeric representation living in a second structure with its own file format and its own lifecycle. Your delete acts on the note. The index was built from the note.

Those are two different objects.

There is a whole discipline devoted to the opposite failure — getting a note back after you removed it by accident, which Trash and Recover a Deleted Note covers at the file layer. This is that problem's mirror image: the copy persists when you wanted it gone.

An index is derived state with its own delete semantics

An index is not a view of your notes. It is a separate structure built from them, and it carries its own definition of the word delete. In graph-based vector indexes that definition is usually mark-now-remove-later, where "later" is a scheduled maintenance job rather than the instant you pressed the key.

The structure explains the behaviour. HNSW is the dominant approach: Yu. A. Malkov and D. A. Yashunin introduced it as "a new approach for the approximate K-nearest neighbor search based on navigable small world graphs with controllable hierarchy (Hierarchical NSW, HNSW)."⁵ Every vector is a node with edges to its neighbours, and search speed comes from the shape of that graph. Pull a node out mid-flight and you have to repair what it was holding together.

So implementations defer it. The paper attributes the deferral to avoiding the heavy input/output cost of restructuring the graph on every removal⁶ — a genuine tradeoff, chosen deliberately, not negligence by any vendor. The consequence, in the authors' own words: "Since soft-delete only modifies API metadata, the vectors remain physically present in the HNSW index (invisible to queries, but intact on disk)."⁷ And the schedule varies: "In some systems, physical removal is deferred until an asynchronous batch cleanup."⁶

Which produces the sentence a note owner should sit with. "Even with vectors physically present on the disk, the controller can still truthfully report that the API has no records for that ID."⁸

Nobody is lying to you. The query layer and the storage layer simply disagree about what happened, and you only ever see the query layer.

The strongest thing about this mechanism is that it is confirmed at three independent levels: the library documents mark_deleted as a mark,¹ the database documents tombstones and a 300-second cleanup cycle,² and an independent measurement found the vectors still there.³

What a leftover vector still yields

A tombstoned vector is not a husk. In that June 2026 preprint, reading the raw index files of three HNSW systems — ChromaDB, FAISS and Weaviate — returned soft-deleted vectors. In the authors' words, those vectors "remain physically recoverable by accessing the raw index files at the storage layer, bypassing API access."³

Inverting them gave back a measurable share of the original content rather than noise, and the rates depend heavily on what was embedded. On a Wikipedia biographical dataset the authors report that "we successfully recover 25.5% of exact person names and 46.4% of geographic locations."³ On highly structured synthetic health records, "recovery reaches 100% for both patient age and gender markers."³ On facial embeddings, "top-1 identity recovery reaches 99%."³

That vectors are invertible at all is not the new claim here, and this post does not re-argue it — The Embedding of Your Note Is Not Anonymous already makes that case with its own evidence. The new claim is narrower and stranger: the vector you asked to destroy is still there to invert.

There is a physical tell, too. Measuring Weaviate 1.26.6, the authors saw the on-disk index grow from 52.5MB to 55.4MB after a logical deletion, because "HNSW slots are not reclaimed; deletion appends metadata instead."⁹

Deleting made the file bigger.

Note the precision the authors themselves insist on: Weaviate's own storage format blocked direct extraction, so persistence there was inferred from that disk growth rather than read back vector by vector.⁹

What this evidence is not

Five limits, stated here before a hostile reader states them for us. The study is a preprint. Its threat model assumes raw file access. Deleted records do not reappear in answers. Recovery is wildly uneven across data types. And nobody has measured any of this on a personal note vault.

• It is a preprint, not peer-reviewed work. The arXiv comments field reads "Prepared for submission." It was submitted on 16 June 2026 and has not been replicated. Read the percentages as one team's measured results on the specific datasets they chose, not as constants. The mechanism does not depend on the paper — the library and the database document it independently¹² — only the recovery numbers do.
• The threat model requires raw storage access. The adversary is assumed to be reading the index files directly, bypassing API restrictions.³ This is not a remote exploit against a running service. For an index on your own machine, that adversary is whoever later holds your disk, your backup, or your synced folder — which is why this is a hygiene problem rather than an attack.
• Your assistant does not start quoting the deleted note. The paper's results section is explicit: "The API correctly returns no results for removed IDs."⁹ Retrieval filters the tombstoned records out at query time. The everyday risk is the durability of a second copy, not wrong answers.
• Recovery is not uniform. In the same study, chest-radiograph embeddings produced classifiers that "failed to separate classes effectively" because inter-class cosine similarity stayed at or above 0.98.⁹ Some modalities give up almost nothing.
• The step from those datasets to your notes is reasoned, not measured. The authors tested Wikipedia biographies, synthetic and real clinical records, medical images and faces. Nobody in this literature has embedded a personal note vault and measured what comes back. The mechanism is documented; the extension to your own writing is an argument by analogy, and should be read as one.

Two more facts belong here, and both cut against the scare reading. The ghosts cost performance as well as privacy: leftover nodes "remain structurally active in the HNSW graph, degrading live search results and creating a timing side-channel that reduces query latency by 4.3% under true deletion."¹⁰ That is precisely why cleanup routines exist at all.

And a fix is cheap. The authors' proposed epoch key rotation "reduces observed PII recovery to 0% and completes in 2.5 ms for 500 deleted vectors."³

This is a solvable problem, not an indictment.

Three moves, cheapest first

Treat the index as a second copy you must be able to destroy. Know where the artifact lives before you need to remove it. Rebuild it after a batch of sensitive deletes instead of trusting a cleanup schedule you cannot see. Then prove the delete propagated with a test you run yourself.

1. Know where the artifact is. This is the whole argument of Own the Vector Index Next to Your Files, and deletion is the case that makes it concrete. If the index is a file sitting beside your notes, removing it is an operation you perform. If it is a row in someone else's service, deletion is a request you make and a status you are shown.
2. Rebuild after a batch of deletes. Rebuilding is already a routine operation — Your Vector Index Is Model-Locked covers the mechanics for the model-switch case. This is the same operation with a different trigger. Delete the sensitive notes, then rebuild from the files rather than waiting out a 300-second timer you may not control.²
3. Verify with an inverted canary. Bury a Canary in Your Notes to Test Your RAG plants a unique string and queries for it to prove reachability. Invert it: delete the canary note, rebuild, and ask again. If the canary still answers, your delete did not propagate. That is a test, not a promise.

Two caveats on the practice. Copies travel — an index file in a backup or a synced folder is a copy you did not rebuild, and it inherits everything the original held. And if you use a bring-your-own-key assistant, the text you choose to send still goes to your chosen provider, including anything that gets embedded there; that path has its own retention story, separate from your disk.

Index hygiene has a housekeeping sibling worth reading alongside this one: Duplicate Notes Poison Your AI Retrieval deals with content you still have, twice.

This post deals with content you no longer have, once.

Frequently asked questions

Does deleting a note remove it from my AI index?

Not automatically. The index is derived state, built separately from your files. In common implementations a delete marks the record invalid so queries skip it, while physical removal waits for a cleanup pass or a rebuild.³⁶ Deleting the note and rebuilding the index are two different operations.

Does soft delete actually delete embeddings?

No. Soft delete modifies metadata, not storage. In the preprint's words, "the vectors remain physically present in the HNSW index (invisible to queries, but intact on disk)."⁷ Weaviate's own documentation describes the same pattern as tombstones cleaned up on a periodic schedule, 300 seconds by default.²

How do I delete data from a vector database?

Issue the delete, then force the cleanup or rebuild rather than assuming it happened. On a local index the reliable move is to remove the index artifact itself and re-embed from your files. Check your system's documentation for its cleanup trigger — the interval is usually configurable and rarely instant.²

Can someone recover a deleted vector?

With direct access to the raw index files, a 2026 preprint recovered soft-deleted vectors from three HNSW systems and partially inverted them.³ Scope it correctly: that is a disk-access threat model, not a remote API attack. The practical exposure is old backups, synced folders and second-hand drives.

Do deleted records slow down vector search?

Yes. Leftover nodes stay structurally active in the graph, and the same study measured a 4.3% query-latency difference under true deletion, alongside degraded live search results.¹⁰ Cleanup routines exist because of this cost, which means performance and privacy point the same direction here.

How do I prove my AI index no longer has the note?

Run an inverted canary. Write a note containing a unique nonsense string, confirm your assistant can retrieve it, then delete the note and rebuild the index. Ask again. If the string still comes back, your delete never reached the index — and now you know before it matters.

Ownership of a note has never stopped at the file. It extends to every copy the file produced, and to whether you can end each one on purpose. A vault you can delete from is the easy half. An index you can locate, rebuild and test is the half that decides whether "deleted" described the world or only described a button.

Deletion is not an event you trigger. It is a property you maintain across every copy your notes have spawned.

If you want the underlying files to stay yours while you work that out, MNMNOTE keeps notes as open Markdown on your own device, with no account — mnmnote.com.