Do vector databases prove deletion?

No. In the open Can Your AI Forget benchmark, pgvector, Qdrant, Chroma, and Pinecone each delete what you point them at and can identify a subject, but none of them produces proof that the deletion happened. Provability is the universal gap - it is the piece you have to add on top.

How do you verify deletion from Pinecone given eventual consistency?

Pinecone deletes are eventually consistent, so a re-query immediately after deleting reflects what the configured endpoint returns at issue time, not a guarantee across every replica. A verifiable certificate should say exactly this - Lethe scopes the claim to verified absent at issue time against the configured endpoint, and carries a valid_until freshness bound so a point-in-time result is not read as a standing claim.

Lethe Delete · how-to

How to prove data deletion from a vector database

Q: Why doesn't deleting the database row remove the data from a vector database?

A DELETE on the source row does not touch the embedding you already wrote to the vector store. The person is gone from Postgres and still perfectly searchable in pgvector, Pinecone, or Qdrant, and often copied again into a RAG index or cache. Real deletion means removing every copy across every retrieval layer, then confirming it.

Deleting the source row leaves the embedding searchable in your vector store. To prove a person is gone you have to delete across every retrieval layer, re-query to confirm zero residual matches, and sign that result into a certificate anyone can verify against a published key. None of the vector databases do this last part for you.

Why a delete isn't a proof

A DELETE on the source row doesn't touch the embedding you already wrote. The subject is gone from Postgres and still perfectly searchable in pgvector, Pinecone, or Qdrant — and frequently copied again into a RAG index or a downstream cache. So "delete this person" spans a stack where their data got copied into three or four places, and a clean database row says nothing about the rest.

In the open "Can Your AI Forget?" benchmark — run against pgvector, Qdrant, Chroma, and Pinecone using each store's own native APIs — every store deletes what you point it at, and not one produces proof the deletion happened. Provability is the universal gap.

The five steps

Track where the subject's data landed. Tag each record to its data subject on write, so a later forget(subject) can find every copy — nothing to remember by hand later.
Delete across every retrieval layer. Remove the records from each configured connector — pgvector, Pinecone, and any RAG index or cache you connect — not just the primary store.
Re-query to confirm absence. Immediately re-query each layer for the deleted ids and record the residual count. Zero residual is the evidence; a non-zero count is residue a re-query found.
Sign the result into a certificate. Emit an Ed25519-signed record of what was deleted, the declared_scope, the re-query behind each layer, and a valid_until freshness bound.
Verify against a pinned public key. Check the signature against the operator's published key — an unpinned check proves self-consistency, not authenticity.

Doing it with Lethe Delete

Lethe Delete (Apache-2.0, self-hosted) wires steps 1–5 as a tag-on-write plus forget(subject) loop that returns the certificate. pip install lethe-delete; wrap your store once, and each write tags itself. An agent can verify the resulting certificate with zero infrastructure — three live certs are at lethe-delete.com/demo. See also what a deletion certificate is.

Honest scope. A certificate proves absence from the configured retrieval layers at issue time — not erasure from backups, model weights, or read replicas. For eventually-consistent stores such as Pinecone it reflects a re-query against the configured endpoint at issue time, not a guarantee across replicas. A self-signed certificate proves self-consistency; independent third-party attestation is a separate layer. This is not legal advice.