How do you delete every vector for one document from a Pinecone serverless index?

## The three delete forms ``` index.delete(ids=["a", "b"], namespace="tenant-a") # by id index.delete(delete_all=True, namespace="tenant-a") # clear a namespace index.delete(filter={...}, namespace="tenant-a") # by metadata (pod-based only) ``` All three are scoped to a single namespace — deleting is never global across namespaces, which is both a safety property and a thing to remember when a cleanup "did nothing" because it ran against the default namespace. ## The serverless restriction that drives the design Delete-by-metadata-filter is **not supported on serverless indexes**. This is the fact the question is really about, and it is not a small operational detail: it means the obvious way to implement "forget this document" or "purge this user's data" is unavailable, and you have to plan for it at ingest time rather than discover it during an incident. The workaround has two moves: **1. Encode the deletion key in the id.** Since delete-by-id always works, make the ids carry the grouping you will need to delete by. The prevailing convention is a prefix and a separator: `doc-4711#chunk-0`, `user-99/doc-3/para-12`. Choose the prefix to match your actual erasure unit — usually the document, sometimes the source file, sometimes the tenant. **2. Enumerate by prefix, then delete.** `index.list(prefix="doc-4711#", namespace="tenant-a")` pages through the ids sharing that prefix, and you feed those pages into `index.delete(ids=[...])`. Keep each delete call to a few hundred ids rather than thousands, for the same request-size reasons that govern upsert batching. **Alternative: namespace as the erasure unit.** If the thing you delete is always a whole tenant or a whole corpus version, put it in its own namespace and clear the namespace in one call. This is dramatically cheaper than id enumeration and is the right shape for hard multi-tenant isolation and for blue/green re-indexing (build the new version in a fresh namespace, cut reads over, then drop the old one). ## When you did not plan ahead If ids are random UUIDs and there is no prefix to page by, you are left with poor options: query with a metadata filter at a large `top_k` to collect ids and delete them (approximate, so you may not get them all in one pass, and you must repeat until empty), or rebuild the namespace from your source of truth without the unwanted records. Both are slow and awkward, which is exactly why the id scheme is an architectural decision made on day one — an interviewer asking this question is usually probing whether you know that. ## Deletes are eventually consistent A delete is a write. It is acknowledged when accepted, and the record stops appearing in queries shortly afterwards, not instantly. Cleanup code that deletes and immediately asserts an empty result set will be intermittently wrong. If your requirement is that the record must never be served after the delete call returns — a data-erasure obligation, say — you enforce that in your own layer with a tombstone or a post-query filter, and treat the Pinecone delete as the eventual physical removal. ## Cost and scale considerations - Deleting a large corpus id-by-id is many requests; a namespace drop is one. Model the erasure unit before you model the query. - Enumeration itself costs requests, so for very large documents prefer coarse prefixes that let one listing pass cover the whole unit. - Re-ingestion is not deletion. If a document shrank from 40 chunks to 30, upserting 30 leaves chunks 30–39 behind as orphans that queries will still return. Deterministic ids make those orphans *findable* by prefix, but you still have to delete them explicitly. Getting this wrong produces stale content resurfacing in RAG answers long after the source was corrected — a genuinely damaging bug and a good thing to volunteer in the answer. ## Answer shape for an interview Name the three delete forms; state the serverless filter restriction plainly; give the id-prefix plus `list` plus batched `delete` recipe; offer namespace-as-erasure-unit as the cheaper design when it fits; and close on the two operational traps — eventual consistency and orphaned chunks after re-ingestion.