Remove vectors from an index
The language tabs use earlier client interfaces. Check SDK versions and connection setup before running them.
Delete embeddings that are no longer needed. Choose the correct index family and use bulk deletion for a list of IDs.
Before you run it: Deleting a source row is separate. Review HNSW repair, bulk limits and ID limits below.
For a safe trial, write the sample vector with ID sku-9281 in a disposable table, then delete that ID. The first result should report an existing entry; a second delete should report that it is already absent. Deleting a vector does not delete the source product row.
- Confirm the IDs and familySelect HNSW, IVF or IVF-PQ for the intended entries.
- Send the bounded deletionUse a single ID or a list within the bulk limit.
- Check deletion resultsInspect existence flags or distinct deleted counts.
- Review HNSW repairDecide whether deleted-node links need the optional repair.
Follow the example
- Confirm IDs and index family.
- Run a single or bulk delete.
- Check the returned result or count.
- For HNSW, decide whether to repair graph links too.
Run the request
curl -X DELETE "https://$OC_HOST/v1/tenants/$OC_TENANT/vector/shop.products/sku-9281" \
-H "Authorization: Bearer $OC_TOKEN"Check the result
A single delete reports whether the entry existed; bulk deletion counts distinct deleted entries.
{
"deleted": true
}deleted is false when nothing was stored under that id. Nothing is written on that path, so a retry costs you a round trip and nothing else.
Query options
| Field | Required | Notes |
|---|---|---|
| index | no | "hnsw" (default), "ivf" or "ivf_pq". Picks which index family the delete dispatches into. |
| repair | no | HNSW only. true re-links the deleted node's neighbours across the hole instead of leaving a tombstone. Ignored on the IVF and IVF-PQ arms, which shrink their posting lists cleanly. |
Delete several IDs
curl -X POST "https://$OC_HOST/v1/tenants/$OC_TENANT/vector/shop.products/delete-bulk" \
-H "Authorization: Bearer $OC_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"ids": ["sku-9281", "sku-1144", "sku-5520"],
"index": "hnsw",
"repair": true
}'Check the deletion count
{
"deleted_count": 2,
"missing_count": 1
}The two counts always sum to the number of distinct ids you sent - duplicates inside one call are de-duplicated server-side and count once.
Understand the behavior
On the HNSW arm a delete tombstones the node: the graph slot stays, the embedding goes. repair: true additionally re-links the neighbours across the hole, at a higher per-call cost. In bulk that repair runs as a single sweep at the end of the batch rather than once per id.
On the IVF and IVF-PQ arms the id is evicted from its cell's posting list and the payload is deleted; there is no topology to repair. Every successful delete also decrements the tenant's stored-embedding counter, so the quota tracks embeddings currently resident rather than embeddings ever written.
A bulk delete writes one entry to the destructive-operations audit trail carrying the counts, the index family and whether repair ran. The ids themselves are deliberately not logged - a vector id is customer-chosen and routinely a document or user key.
Important limits and checks
- Treating a missing id as an error. Both routes return 200 for an id that was not there. Assert on
deleted/deleted_count, not on the status code. - Forgetting
indexon an IVF table. The dispatch defaults to HNSW. Delete an IVF row without?index=ivfand the cell posting still lists it. - Sending more than 10,000 ids. That is the per-request cap and it is a 400, not a truncation. Page your own list.
- Expecting
repairto help an IVF delete. It is accepted on both arms so one client shape works everywhere, but it only does anything on HNSW. - Very long ids. A vector id over 1 KiB is refused with 400 - the limit exists so the hash and write path stay bounded.