Pinecone clear namespace not working?

[f.dig]

Describe the problem/error/question

When using the Clear Namespace option in Pinecode node, the namespace isn’t cleared and i can find old records

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[AlvLeoAI]

This usually isn’t an n8n bug, the “clear namespace” action maps to Pinecone’s delete-everything in a namespace operation. If you still “see old records” afterwards, it’s almost always one of the issues below.

What to check (in order)

1. Give Pinecone a moment (eventual consistency).
   Deletions are not instantly visible. Pinecone is eventually consistent—queries right after a write/delete can still return stale results for a short time.

• How to verify: call Describe index stats / check vector count as Pinecone suggests on their “Check data freshness” page, then retry your query after a brief delay/backoff.

2. Make sure you’re querying the same namespace you cleared.
   Namespaces partition data. A query without the same namespace parameter won’t reflect what you just cleared. In n8n, set the exact namespace on both:

• the node where you cleared the namespace, and
• the node where you query (or you’ll query another namespace—often the default).

3. Know which deletion API your index supports (serverless vs pods).

• Serverless indexes have a Delete Namespace endpoint that permanently removes a namespace.
• Pod-based indexes don’t support that endpoint; you must use the classic delete with the delete all in namespace flag (e.g., index.delete(delete_all=True, namespace="example")).
  If your n8n node is talking to a pod-based index but you expect serverless “delete namespace” behavior, it will seem like “clear” isn’t working.

4. Expect an empty {} response from delete—but data removal is async.
   Pinecone’s delete calls often return {} immediately while the vector removal finishes in the background; community threads confirm a short lag even on serverless. Verify after a delay using stats (step 1).
5. If you used filters, test a blind ‘delete all’.
   Filtered deletes can be tricky; Pinecone has past reports of filters not matching as expected. In n8n, first run Clear namespace (no filter) to prove deletion works; then re-add a filtered delete if you truly need it.

Quick sanity test outside n8n

• Serverless index (namespace hard-delete):

# DELETE /namespaces/{namespace}
# permanently removes the namespace (serverless only)

Pinecone docs: Delete a namespace.

• Pod-based index (delete all in namespace):

index.delete(delete_all=True, namespace="your_ns")  # deletes all vectors in that namespace

Pinecone confirms this pattern for whole-namespace deletion.

Then query with the same namespace and confirm zero matches after a short wait (eventual consistency).

---

If it still “doesn’t clear”

• Double-check you’re hitting the correct index + environment/region (easy to mix credentials/regions).
• Confirm serverless vs pod type and apply the correct delete method (step 3).
• Add a retry/backoff on the first query after deletion (because of eventual consistency).
• As a final step, use Pinecone’s “Delete Namespace” endpoint on serverless (or delete_all=True on pods) directly to isolate whether the issue is with Pinecone or with how the n8n node is configured.

If you can share which index type you’re on (serverless or pods), the namespace value you’re clearing, and how/where you’re querying afterwards, I can suggest the exact n8n node settings to make this robust (including a tiny wait + stats check).

Worked for 5 minutes

Pinecone’s “clear namespace” behaviour depends on which type of index you’re using and how you call it:

• Deletion is asynchronous and eventually consistent. The Pinecone docs warn that their database is eventually consistent, so there can be a short delay between issuing a delete and the change being visible. They specifically note in the “Data freshness” section that “Pinecone is eventually consistent, so there can be a slight delay before new or changed records are visible to queries”
  
  docs.pinecone.io. This means if you delete a namespace and query it immediately afterwards, you may still see stale vectors. The recommended way to confirm that the deletion has finished is to poll the describe_index_stats endpoint until the namespace and its record count disappear
  
  community.pinecone.io.
• Know which API your index supports.
  – Serverless indexes support the delete_namespace operation. The docs describe it as “delete a namespace and all of its records” and note that deleting a namespace is irreversible
  
  docs.pinecone.io. However, it’s only available in serverless indexes and not when using the pinecone[grpc] client.
  – Pod‑based (gRPC) indexes do not support delete_namespace. In this case you must delete all vectors in the namespace using the delete API with the delete_all flag: index.delete(delete_all=True, namespace="example"). A Pinecone engineer explains that calling delete_all=True will remove all vectors in the specified namespace
  
  community.pinecone.io. Like any deletion, this call is asynchronous
  
  community.pinecone.io.
• API availability can change. Pinecone staff have acknowledged that the delete_all functionality was briefly unavailable due to internal changes but would be reintroduced; the workaround is to drop and recreate the index
  
  community.pinecone.io. If you are on a Starter plan or using an older SDK version, this might be why the clear‑namespace option appears to do nothing.
• Make sure you’re querying the same namespace you cleared. Pinecone’s namespaces are separate; if you clear one namespace but run your query without specifying a namespace, it will fall back to the default and still return old records.

What this means for n8n:

1. Verify whether your Pinecone index is serverless or pod‑based. The “Clear Namespace” option in n8n’s Pinecone node will call delete_namespace on serverless indexes, but will use delete_all=True on pod‑based indexes.
2. After running the Clear Namespace node, wait a few seconds or add a delay before running your next query. You can also add an HTTP Request node to call describe_index_stats and check that the namespace’s record count has dropped to zero.
3. Ensure that both the Clear Namespace node and any subsequent query nodes use exactly the same namespace value; otherwise you’ll delete one namespace and query another.
4. If deletion still appears to fail and your account is on the Starter tier, consider opening a support ticket with Pinecone; there have been periods when the delete_all API was disabled and the only workaround is to recreate the index
   
   community.pinecone.io.

By following these steps you should see that the namespace is actually cleared—just remember that Pinecone deletes are async and may not take effect instantly.

[jabbson]

Hey @f.dig, hope all is good.

All you need to do is change the namespace, in my previous tests clear namespace only worked for non-default namespaces.

You can specify the namespace with another option:

[siebird]

I’m actually getting the exact opposite behavior. My workflow kept only the last run of records in Pinecone with clear namespace option enabled. Took me forever to figure this out.

I disabled it, and all records are imported. How does the clear namespace option work? For now, I’ll add a step to hit the pinecone api to clear the namespace manually.

[jabbson]

@siebird

I disabled it, and all records are imported. How does the clear namespace option work? For now, I’ll add a step to hit the pinecone api to clear the namespace manually

very simple - if you have it enabled, before ingesting any records, it deletes all existing, so what you are describing is actually WAI.

[siebird]

Maybe it’s because I have the embedding batch size set to 25 and have 300+ records to ingest.

My assumption was that it would clear in the first batch, but it’s clearing every batch.