Delete data
This page shows you how to use the delete endpoint to remove records from an index namespace.
Delete records by ID
Since Pinecone records can always be efficiently accessed using their ID, deleting by ID is the most efficient way to remove specific records.
To remove records from the default "" namespace, don’t specify a namespace in your request.
Delete records by metadata
Serverless indexes do not support deleting by metadata. You can delete records by ID prefix instead.
In pod-based indexes, if you are targeting a large number of records for deletion and the index has active read traffic, consider deleting records in batches.
To delete records based on their metadata, pass a metadata filter expression to the delete operation. This deletes all vectors matching the metadata filter expression.
For example, to delete all vectors with genre “documentary” and year 2019 from an index, use the following code:
Delete an entire namespace
In pod-based indexes, reads and writes share compute resources, so deleting an entire namespace with many records can increase the latency of read operations. In such cases, consider deleting records in batches.
To delete an entire namespace and all of its records, provide a namespace parameter and specify the appropriate deleteAll parameter for your SDK. To target the default namespace, set namespace to "".
Delete records in batches
This guidance applies to pod-based indexes only. In serverless indexes, it’s safe to delete an entire namespace or a large number of records at once because reads and writes do not share compute resources.
In pod-based indexes, reads and writes share compute resources, so deleting an entire namespace or a large number of records can increase the latency of read operations. To avoid this, delete records in batches of up to 1000, with a brief sleep between requests. Consider using smaller batches if the index has active read traffic.
Delete an entire index
To remove all records from an index, delete the index and recreate it.
Data freshness
Pinecone is eventually consistent, so there can be a slight delay before new or changed records are visible to queries. You can use the describe_index_stats endpoint to check data freshness.
Was this page helpful?