Updating, Deleting and Concurrency

Why Writes Need Care

Vectors go stale when their source documents change. A knowledge base that never updates quietly answers from old text, so plan deletions and re-embedding from day one.

Idempotent Upserts

Re-running a sync must not duplicate rows. Hash the content into the point id so re-adding the same text updates the existing vector instead of inserting a copy.

import hashlib

def point_id(source, chunk):
    return hashlib.sha1((source + chunk).encode()).hexdigest()

ids = [point_id("guide.md", c) for c in chunks]

Delete by Id, Filter or Collection

# ChromaDB
collection.delete(ids=["old-1", "old-2"])
collection.delete(where={"source": "deleted-file.md"})

# Qdrant
client.delete(collection_name="kb", ids=["old-1"])
client.delete(
    collection_name="kb",
    points_selector=Filter(must=[
        FieldCondition(key="source", match=MatchValue(value="deleted-file.md")),
    ]),
)

Concurrency Notes

Modern builders handle concurrent reads during writes with no locking on your side. Do writes in batches, not row by row, and let the content-hash decide update versus insert instead of maintaining your own lock table.

Key Points

• Stale vectors are the top silent failure in production.
• Content hashes make re-syncs idempotent.
• Delete by ids, filters or whole collections.
• Batch writes; reads stay safe during writes.