What are ghost vectors in vector databases?

Short answer: a ghost vector is an embedding that stays inside a vector database after the record it stood for was deleted. The delete call flags it and hides it from queries, but the numbers stay on disk until a later cleanup runs, and during that window the data can be read back.

That window is the whole problem. A delete that returns success looks like erasure and often is not, because the vector store, the approximate-search index in front of it, and the backups behind both keep their own copies on their own schedules. This piece covers what a ghost vector is, why the major databases leave them behind by design, whether a deleted embedding can really be reconstructed, and why a residual vector can fail both a compliance request and the answer a user sees.

What exactly is a ghost vector?

A ghost vector is a leftover embedding: a numeric vector that keeps sitting in the index after its source document was removed. Nothing points to it from the outside, queries are told to skip it, and yet the vector itself, with everything encoded in it, is still there on disk.

The name is recent. A June 2026 security paper, 'Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases,' uses the term for exactly this case: a record a user asked to delete, where the system, in the authors' words, typically only marks the record as deleted, leaving the embedding on disk physically unchanged. Engineers have described the same thing in older language for years, as orphaned, residual, or tombstoned embeddings. The phenomenon is older than the name.

Why does deleting a vector leave one behind?

Because the index it lives in is costly to edit. Approximate-nearest-neighbor structures like HNSW are graphs, and pulling one node out cleanly is slow, so most databases take a shortcut: they mark the vector deleted, skip it at query time, and reclaim the space later in a batch.

Milvus documents the tradeoff in its own FAQ. Asked whether storage is released right after deletion, the answer is no: a delete marks entities as logically deleted, a background compaction later merges segments and drops the deleted data, and a separate garbage-collection pass frees the space, which the FAQ says can introduce a slight delay between deletion and space reclamation. That delay is the ghost vector's lifespan, and it is set by the cleanup schedule, not by your delete call.

How do the major vector databases actually handle a delete?

Nearly all of them defer the physical removal. A delete marks the vector, hides it from results, and hands the real cleanup to a background job that runs on a schedule you configure. Until that job runs, the deleted vector is still on disk. Here is what the vendors document.

• ·Milvus marks deleted entities as logically deleted, then reclaims space through a background compaction and a later garbage-collection pass, with what its FAQ calls a slight delay between deletion and space reclamation. https://milvus.io/docs/product_faq.md
• ·Qdrant does not delete entries immediately; it marks records as deleted and ignores them for future queries, and a Vacuum Optimizer only rebuilds a segment once deleted vectors cross deleted_threshold (default 0.2, one fifth of the segment) and vacuum_min_vector_number (default 1000). https://qdrant.tech/documentation/ops-optimization/optimizer/
• ·Weaviate attaches a tombstone to each deleted object in the HNSW graph and clears tombstones on a timer, cleanupIntervalSeconds, which defaults to 300 seconds. https://docs.weaviate.io/weaviate/config-refs/indexing/vector-index
• ·pgvector leaves deleted rows as dead tuples inside the HNSW index until VACUUM runs, and its own README warns that a query can return even less results due to dead tuples. https://github.com/pgvector/pgvector/blob/master/README.md
• ·Pinecone is eventually consistent: after a delete, in its docs' own words, there can be a slight delay before new or changed records are visible to queries. https://docs.pinecone.io/guides/data/data-freshness/understanding-data-freshness
• ·Chroma issue #3793: a user deleted 26 of 31 documents and the database grew from 0.73MB to 0.80MB, because the deleted text and embeddings were still parked in an internal queue table. https://github.com/chroma-core/chroma/issues/3793

Can someone read a deleted embedding back into the original data?

Yes. An embedding is a dense encoding of its input, and published attacks invert that encoding back into text and identities. So a ghost vector is not harmless dead weight. For as long as it stays readable on disk, the personal data it carries stays recoverable by someone who reaches the storage layer.

Embeddings were treated as anonymous for years, and that assumption broke. In 'Text Embeddings Reveal (Almost) As Much As Text,' Morris and colleagues showed a method that recovers 92 percent of 32-token inputs exactly and pulls full names out of a dataset of clinical notes, working from the vectors alone. The 2026 Ghost Vectors paper takes the attack to the storage layer: reading raw HNSW index files and running an off-the-shelf inversion model, the authors recovered 25.5 percent of exact person names and 46.4 percent of geographic locations from a Wikipedia dataset of living people, 100 percent of patient age and gender markers on synthetic health records, and 99 percent top-one identity on facial embeddings. Our explainer on machine unlearning, at /blog/what-is-machine-unlearning, goes deeper on the embedding-inversion work behind these results.

Why do ghost vectors matter for GDPR and KVKK erasure?

Because the right to erasure follows the data, not the table. GDPR Article 17 says a controller must erase personal data without undue delay. A vector store still holding a recoverable embedding of someone who asked to be deleted has not finished the job, whatever the source database now shows.

Article 17 sets the erasure duty, and Article 83 sets the price of missing it, fines up to 20 million euros or 4 percent of worldwide annual turnover, whichever is higher. Turkey's KVKK carries the same duty under Article 7 of Law 6698, which requires deletion, destruction, or anonymization on request. The reach is wide even inside a managed stack. Amazon's own guide for handling right-to-be-forgotten requests in Bedrock Knowledge Bases notes that after a delete the service account still keeps the data for eight days before it is purged, and that removing it from backups is, in AWS's words, the responsibility of the customer. Our companion pieces on the right to be forgotten and on what deletion does not reach, at /blog/right-to-be-forgotten-and-ai-chatbots and /blog/does-deleting-data-remove-it-from-ai-models, track that enforcement record in full.

Do ghost vectors also break retrieval, not just compliance?

Yes, in a quieter way. A vector that was deleted but not yet cleaned up can still score as a close match and get handed to the model. So the system keeps answering from content you meant to remove, and the failure shows up as a wrong answer, not an error.

The retrieval path shows it plainly. Pinecone's docs say a deleted record can stay visible to queries for a short window after the delete returns, and pgvector warns that dead tuples change what a query gives back. Stale and duplicate embeddings compound the effect: one engineer's write-up on the RAG freshness problem describes deprecated content that keeps scoring as a top match long after it should have dropped out of the results. A ghost vector does not announce itself. It quietly keeps feeding the model something you already tried to delete.

How do you prove a vector store has no ghost vectors?

You test the store after the deletion, at the layer a query touches, not the delete routine that reported success. Plant known markers before erasure, delete them, then probe the index and its retrieval path to see whether the vectors, or anything invertible from them, still come back.

This is the audit ZeroRecall runs. After you delete someone's data, we plant canaries in your vector store, delete them, then probe the index and its retrieval path to see whether the vectors, or text inverted from them, still surface. The output is a FORGET score and a hash-chained, ECDSA-signed evidence file that anyone can verify without trusting us. Every finding is scoped to the behavior observed on the listed surfaces at the stated date, because that is what the evidence supports, not a claim that the data is gone from every backup forever. The Ghost Vectors researchers land in the same place: their proposed fix ends in an ECDSA-signed proof of the deletion event. You can verify a real evidence file at /verify, see how the audit works at /#how, or check the published price at /pricing.

Sources

Every number above maps to a live source. Check them yourself.

• ·Term 'ghost vectors', soft-deleted embeddings remain physically on disk and reconstructible, recovery rates (25.5% names, 46.4% locations, 100% patient age/gender, 99% facial identity), and an ECDSA-signed proof of deletion as the proposed fix: Chakraborttii et al., Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases, 16 June 2026. https://arxiv.org/abs/2606.18497
• ·92% exact recovery of 32-token inputs and full names recovered from clinical notes, from embeddings alone: Morris, Kuleshov, Shmatikov, and Rush, Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023. https://arxiv.org/abs/2310.06816
• ·Storage not released right after deletion; logical delete, then background compaction and garbage collection with a slight delay before space is reclaimed: Milvus Product FAQ. https://milvus.io/docs/product_faq.md
• ·Deleted records marked and ignored for queries; Vacuum Optimizer thresholds deleted_threshold (default 0.2) and vacuum_min_vector_number (default 1000): Qdrant documentation, Optimizer. https://qdrant.tech/documentation/ops-optimization/optimizer/
• ·Tombstones mark deleted objects in the HNSW index; cleanupIntervalSeconds defaults to 300 seconds: Weaviate documentation, Vector index config. https://docs.weaviate.io/weaviate/config-refs/indexing/vector-index
• ·Dead tuples remain in the HNSW index until VACUUM, and a query can return even less results due to dead tuples: pgvector README, pgvector/pgvector. https://github.com/pgvector/pgvector/blob/master/README.md
• ·Eventual consistency, a slight delay before new or changed records are visible to queries after a delete: Pinecone documentation, Understanding data freshness. https://docs.pinecone.io/guides/data/data-freshness/understanding-data-freshness
• ·Deleted-document persistence (26 of 31 docs deleted, database grew 0.73MB to 0.80MB, data left in an internal queue table): chroma-core/chroma, GitHub issue #3793, 2025. https://github.com/chroma-core/chroma/issues/3793
• ·Bedrock Knowledge Bases: service account keeps deleted data for eight days before purge, and removing it from backups is the responsibility of the customer: Tatavarthi, Prasad, and Sampathkumar, AWS Machine Learning Blog, 31 May 2024. https://aws.amazon.com/blogs/machine-learning/implementing-knowledge-bases-for-amazon-bedrock-in-support-of-gdpr-right-to-be-forgotten-requests/
• ·Right to erasure without undue delay: GDPR Article 17. https://gdpr-info.eu/art-17-gdpr/
• ·Fines up to 20 million euros or 4% of worldwide annual turnover: GDPR Article 83. https://gdpr-info.eu/art-83-gdpr/
• ·Deletion, destruction, or anonymization on request: KVKK Law 6698, Article 7. https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law
• ·Stale embeddings keep scoring as top matches and degrade retrieval quality over time (one engineer's analysis): Tian Pan, The RAG Freshness Problem, 10 April 2026. https://tianpan.co/blog/2026-04-10-rag-freshness-problem-stale-embeddings-silent-failure