Hi, my company recently migrated to Pinecone Serverless. We noticed that deleting vectors by ID does not behave as expected. When we send a delete request (using the Python Pinecone SDK), we immediately get a response. But if we check the index afterwards, we see that the vectors are still there. It’s only after several seconds that they actually get deleted. It appears that the delete endpoint just queues up the vectors to be deleted.
Is this the case? If so, how can we know exactly when the vectors are in fact deleted?
Hi @shobrookj, Pinecone is eventually consistent, so there can be a slight delay before new or changed records are visible to queries and other read requests.
After adding, updating, or deleting records, use the describe_index_stats operation to check if the current record count matches the number of records you expect.
Please note that Pinecone serverless is in public preview. Performance may fluctuate, and we are continuously improving the architecture, including data freshness capabilities.
Thanks for the response. For our use case, we need to know for sure that the vectors are deleted before performing another operation, otherwise our system will break. It sounds like the best way to do this is to continuously poll describe_index_stats until it reflects the right record count? Are there plans to implement a better solution down the line, such as simply waiting to return a response from the /delete request until the vectors are actually deleted?
@shobrookj Yes, you are correct that the best approach at this time is to poll describe_index_stats until you observe the expected vector count.
There are a few considerations regarding how this challenge will be handled in the future:
- We aim to continue improving our data freshness capabilities on serverless so that this situation is less likely to emerge.
- We are working on functionality that allows users to bind their read requests to ensure that certain previously issued writes are reflected in the freshness layer used for the read. This will effectively ensure that you can perform a read, knowing that the impact of your write requests is present.
Lastly, I’m curious how many records you are deleting in one request before you test the effect with a fetch.
Okay, point #2 sounds great.
One last question: I’m noticing that Pinecone serverless does not support metadata filtering for the describe_index_stats method. I group together vectors based on metadata, and this means I cannot check if the deletion for a particular group of vectors was successful or not. What would you recommend I do?