Remove deleted documents from every RAG storage layer

Deleting a source from a document table can leave its content available through vectors, cached answers or a stored excerpt. A retrieval system needs a deletion policy that identifies every derived representation and prevents new reads while cleanup proceeds.

For a synthetic source called export-guide, list the original file, parsed text, chunk rows and embeddings. Add query-result caches, generated-answer caches and any snapshots retained for audit. Each layer needs an ownership reference back to the source and revision.

The pgvector documentation includes ordinary SQL updates and deletes for vector-bearing rows. It does not remove application caches or copied text in other systems.

Deletion event reaching metadata, vector rows and cached answers.

Deny new retrieval before slow cleanup

A deletion can first mark the source unavailable in authoritative metadata. Retrieval should consult that state so a delayed background cleanup cannot keep serving the source. Then remove or retire the derived records according to the retention policy.

If storage layers cannot share a transaction, use a durable cleanup job with an idempotent record of progress. Retrying a vector deletion should be safe when the rows are already gone. A completed status needs evidence that all required layers were processed, not merely that the job started.

Cache invalidation is easy to overlook. A response cache keyed only by question text may continue returning a complete answer after its only supporting source disappears. Store source dependencies with cached answers so deletion can invalidate them, or enforce source availability when serving the cached result.

Exercise a deletion race

In a disposable fixture, index two sources, ask a question that retrieves the first, then delete that source. Repeat the question and attempt to open its earlier citation. Check fresh retrieval, cached responses and citation access separately.

Also start an ingestion job before deletion and let it finish afterwards. Without a tombstone or revision check, a delayed worker can recreate the deleted chunks. Verify the source is still eligible before activating an ingested revision.

A deleted source may appear in historical logs or backups under a different retention obligation. Document that policy separately and restrict access; do not label an item fully erased if copies are intentionally retained. Logs should avoid storing unnecessary full text in the first place.

This workflow does not promise immediate physical erasure from every backup medium. It defines a testable application behavior: the deleted source stops contributing to new answers, cleanup is traceable, and remaining retained copies have an explicit policy.

Treat permission revocation with similar urgency for serving behavior, even when the underlying file must remain stored for another authorized user.