Skip to main content
This page shows you how to update documents in a collection. The examples write to the default branch, main. The REST request accepts an optional branch field. To write to another branch, create it first, then include its name in branch; a tag or alias is not a valid write target.
If the collection contains native embedding vector fields, update the configured source text fields instead of sending direct vector values for native embedding fields. Unchanged source text reuses an existing vector; see Native embedding write behavior.
Each document in a payload must contain an id field to uniquely identify a document to update. For a partitioned collection, a document in the __default__ partition with a matching id value is updated if the partition field is not provided.

How fields are updated

An update reads the existing document with strong consistency, merges the supplied fields into it, and submits the resulting document for indexing. Omitted fields remain unchanged. The resulting document must still satisfy the collection’s field types and document-size limit. For example, assume metadata is an object field and labels is a keyword field. Start with this document:
Send this update request:
After the update becomes visible, the document is:
An empty object does not clear an existing object. To remove fields, use upsert with the complete replacement document and omit those fields.

Missing documents and failed requests

Update does not create documents. If any ID is missing from the selected branch and partition, the request returns HTTP 400 and none of its updates are submitted. Use upsert when a document may not exist. Updating a partitioned document requires its existing partition-field value; omitting that field selects __default__ and does not move a document from another partition. Input validation and native embedding generation complete before the merged documents are submitted. A failure in either stage prevents submission of the whole update request. A 202 Accepted response confirms acceptance, not completed indexing. A timeout or transport failure after submission can still leave the write applied; verify the resulting state before retrying.

Concurrent updates and cost

Update is a read-modify-write operation without a document-version precondition. Concurrent requests can read the same earlier document and submit different replacements, overwriting each other’s changes even when they update different fields. Serialize writes to the same document when preserving concurrent changes matters. The internal strongly consistent fetch is billed as read usage in addition to the update’s write usage. See Write usage.

Update limits